I built a tool I use every day: Podcast Summarizer with Perplexity AI

Every week I watch podcasts across tech, football, and business. I listen while commuting, while cooking, while going through my morning routine. Then, a week later, I'm in a conversation where the topic comes up — and I can't remember the key points. I know the podcast covered it. I know the guest said something worth repeating. But the details are gone.

I wanted a way to quickly scan what a podcast covered before a conversation. Something that gave me the structure: what was talked about, what the key arguments were, a few direct quotes. Existing tools don't solve this well. Podcast apps have transcripts, but transcripts aren't readable — they're walls of spoken-word text with no hierarchy. AI search tools are generic. Written summaries, if they exist at all, are either padded fluff or nowhere to be found.

So I built it myself.

What it does

The tool is simple. You paste a YouTube URL. Perplexity AI reads the transcript and generates a structured article: sections with headings, a few direct quotes, tags. The output isn't a summary — it's a readable piece you can scan in five minutes. The library grows over time, so every podcast you've processed is searchable.

The live app is at podcast-blog-v2.vercel.app. The workflow is: paste URL, wait about 20 seconds, read the article. If you process a podcast you've already done, it pulls from the database rather than calling the API again.

The output looks like a real article: an intro, several headed sections covering the main topics, a few quotes worth keeping, and tags that make it searchable.

The AI part: Perplexity sonar-reasoning-pro

The model choice was deliberate. I use sonar-reasoning-pro from Perplexity — powerful enough to produce quality output, cheap enough that I never think about the cost. Each summary costs roughly €0.01. At that price, I can process every podcast I listen to without it mattering.

The interesting part is prompt engineering. Without constraints, AI summaries are generic. "The speakers discussed the challenges of X" is useless — it tells you nothing you couldn't have guessed from the title. The system prompt enforces specific structure: meaningful section headings, a minimum word count per section, two to three direct quotes (not paraphrases — actual quotes), and a hard rule against padding phrases.

The API call itself is straightforward:

const response = await fetch("https://api.perplexity.ai/chat/completions", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.PERPLEXITY_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "sonar-reasoning-pro",
    messages: [
      { role: "system", content: SYSTEM_PROMPT },
      { role: "user", content: `Summarize this podcast: ${youtubeUrl}` },
    ],
  }),
});

The system prompt is what does the actual work. It specifies the required sections, minimum lengths for each, the quoting rule, and an explicit instruction to avoid the filler phrases AI defaults to. Getting this right took several iterations — the early versions were still generic, just better-formatted generic.

Supabase as the whole backend

The backend is one service: Supabase. Auth, database, and session management — everything runs through it. Users can sign in with GitHub OAuth or email and password. Sessions are handled with HTTP-only cookies via @supabase/ssr, so the auth state survives page refreshes without exposing tokens to the client.

The most interesting database decision: the article body is stored in a JSONB column rather than flat text. Each article is a structured JSON object — sections, headings, content, quotes. This matches the shape of the AI output and makes rendering it correctly straightforward. Flat text would lose the hierarchy. JSONB preserves it and gives you a flexible schema that can accommodate whatever structure the model produces.

Supabase's free tier handles personal-scale usage without issue. The only friction in setup was configuring SSR auth — @supabase/ssr has specific requirements for how you initialise the client in different contexts: server components, route handlers, middleware. Once it's wired correctly, it just works.

The personal tool philosophy

There's a specific kind of side project worth finishing: one you'll actually use. Most side projects die halfway through because the motivation is learning or showing off, not solving a real problem you have. Those projects feel like work once the interesting parts are done.

The Podcast Summarizer is different. I use it after almost every podcast I listen to. That usage is the best forcing function for polish: you notice the rough edges because you hit them yourself. You fix the bug where the summary cuts off halfway because you saw it happen to a podcast you cared about. You add the search feature because you wanted to find that quote from three weeks ago.

The projects I've actually finished are the ones where I was the first and most frequent user. The Podcast Summarizer is the clearest example of that in my work. It wasn't built to impress anyone. It was built because I needed it.

Where to find it

The project is on GitHub and the live app is at podcast-blog-v2.vercel.app. If you listen to a lot of podcasts and want a searchable archive of what you've covered, it works.

If I kept iterating, I'd add bulk import — a way to paste a list of YouTube URLs and process them all overnight. The individual workflow is fine, but there's a backlog of older podcasts I'd want to retroactively work through.