DEV Community

seller-mind
seller-mind

Posted on

Building an AI Podcast Workflow: My Retrospective and Mistakes

When I first launched my podcast, I genuinely thought the hardest part would be getting guests to agree to an interview or spending hours editing out the "ums," "ahs," and awkward silences. I was completely wrong. The real bottleneck turned out to be everything that happened after the recording stopped and the audio was exported.

I found myself staring at a blank text editor for an hour, trying to come up with a single catchy title. Then, I’d spend another hour trying to format a messy, auto-generated transcript into readable, structured show notes. It was mentally draining. I was spending 80% of my time on administrative overhead and only 20% on actual creative content. The passion I had for the topic was being eclipsed by the friction of the workflow.

So, I decided to build something.

The problem with podcast post-production isn't just that it's tedious; it's that it directly impacts your show's growth and discoverability. If your title is boring or generic, nobody clicks. It's that simple. If your show notes are just a giant, unformatted wall of text, search engines can't index your content properly. Listeners won't find the specific topics they care about, and your episode gets buried in the archives.

Ignoring this administrative friction has a very real cost: creator burnout. I watched so many talented creators quit podcasting within their first ten episodes simply because they couldn't sustain the operational overhead. I wanted to solve this friction for myself, and hopefully for other independent creators. That’s how the foundation for PodCrisp started.

I knew I needed AI to handle the heavy lifting of text generation and summarization, but I had strong opinions on the underlying infrastructure. I didn't want to manage heavy, expensive GPU servers, and I certainly didn't want to deal with unpredictable cold starts that would frustrate users. I decided to build the entire platform on Cloudflare Workers, utilizing AI inference at the edge.

The main trade-off with edge AI is that the models are generally smaller and have smaller context windows compared to the massive foundational models running in centralized data centers. This meant I couldn't just throw a massive, vague prompt at the model and hope for the best. I had to be incredibly precise with my prompt engineering to get reliable, high-quality outputs.

Take the title generator, for example. In my early tests, the AI was giving me incredibly generic, clickbaity titles that didn't actually reflect the episode content. I had to restructure the prompt to enforce strict rules and constraints. Here is the prompt engineering logic I use for the title generator:

// Prompt engineering for podcast title generation
function buildTitlePrompt(topic, tone, count) {
  return {
    system: `You are an expert podcast producer. Generate compelling titles.
Rules:
- 5-10 words each
- Use curiosity gaps, numbers, or strong hooks
- Match the tone: ${tone}
- No clickbait that overpromises
- Format as numbered list`,
    user: `Episode topic: ${topic}

Generate ${count} title options that make someone want to click play.`
  };
}

// Example: generate 5 titles for a bootstrapping episode
const prompt = buildTitlePrompt(
  "How to start a podcast with zero budget",
  "inspirational",
  5
);
Enter fullscreen mode Exit fullscreen mode

By explicitly telling the model what not to do (no clickbait that overpromises) and constraining the length (5-10 words), the output quality improved dramatically.

I applied a similar philosophy to the show notes generator. Instead of just asking the AI to "summarize this," I built a specific pipeline using Cloudflare Workers to enforce a strict structure. Here is a simplified look at how that edge function operates:

// Show notes generation pipeline (Cloudflare Workers + AI)
export default {
  async fetch(request, env) {
    const { transcript } = await request.json();

    // Call AI model for structured show notes
    const response = await env.AI.run('@cf/meta/llama-3-8b-instruct', {
      messages: [
        {
          role: 'system',
          content: `Convert podcast transcripts to show notes:
## Episode Summary (2-3 sentences)
## Key Takeaways (5-7 bullet points)
## Timestamps (estimate from content flow)
## Resources Mentioned`
        },
        { role: 'user', content: transcript }
      ],
      max_tokens: 800,
    });

    return new Response(JSON.stringify(response), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};
Enter fullscreen mode Exit fullscreen mode

Moving to the edge was a great technical decision. The latency is incredibly low, meaning users get their generated titles and show notes almost instantaneously, regardless of where they are in the world.

What surprised me the most during this build was how much the system prompt matters compared to the raw size of the model. I initially thought I needed to upgrade to a larger, more expensive model to get better show notes. Instead, I just tweaked the system instructions to explicitly define the Markdown structure I wanted, and the smaller edge model handled it perfectly.

If I could do it over, I’d simplify my SEO keyword suggestion feature much earlier in the process. I originally tried to make it analyze the entire transcript and output complex semantic clusters. It was over-engineered, slow, and honestly, overwhelming for the user. I stripped it back to just suggesting 5-10 highly relevant keywords based on the episode summary. Keeping it simple made the tool much faster and actually more useful.

If you're a podcaster struggling with the post-production admin, or just a developer curious about edge AI prompting, I'd love for you to try the tools I've built. I've made the core title generator completely free to use so you can see how the prompting works in practice.

You can try the Podcast Title Generator here.


Full disclosure: I'm the developer of PodCrisp. I built this because I needed it myself.

Top comments (0)