When I first started my tech podcast, I thought the hard part would be the recording. I was wrong. The real time sink happened after I hit 'stop recording.' I'd spend hours listening to my own rambling, trying to pull out key timestamps, writing descriptions, and staring at a blank screen trying to come up with a title that didn't sound like a boring college lecture. I was spending 80% of my time on admin and 20% on actual content. So I decided to build something.

The problem with podcast post-production isn't just that it's tedious; it's the context switching. You go from being a creative speaker to an analytical editor, then to a marketing copywriter. Every time you switch contexts, you lose momentum. For indie creators and solo developers, this administrative overhead is a primary reason podcasts get abandoned. If you can't streamline the transition from raw audio to a published, searchable episode, the friction will eventually win. You need a way to automate the structural work without losing the authentic voice of the episode.

When I started mapping out the architecture, I knew I wanted to avoid the traditional setup of a frontend calling a centralized AI API. The latency, combined with the cold starts of standard serverless functions, made for a clunky user experience. I decided to build the entire pipeline on Cloudflare Workers, utilizing their Workers AI platform to run inference directly at the edge.

Here is the core of the show notes generation pipeline:

// 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' }, }); }, }; 

Let's break down why this structure works. First, by using env.AI.run, we are executing the model directly within the Cloudflare network. There is no external API call to a third-party provider, which eliminates egress costs and significantly reduces latency. For example, inference times for generating show notes from a standard transcript typically drop to under two seconds.

Second, the system prompt is doing the heavy lifting for formatting. Notice how I explicitly define the markdown headers and constrain the output length (2-3 sentences, 5-7 bullet points). Without these strict boundaries, the model tends to ramble or hallucinate extra sections.

For the title generation, I use a similar prompt engineering approach. I instruct the model to act as an expert producer, enforcing rules like using curiosity gaps, avoiding clickbait, and matching a specific tone. The key is treating the LLM not as a magic black box, but as a junior developer that needs very explicit requirements to produce good code—or in this case, good copy.

The edge deployment worked surprisingly well in practice. What surprised me was how much the system prompt structure mattered compared to just tweaking the temperature settings. Constraining the output format yielded much more consistent results.

What I would change? I initially tried to pass the entire raw transcript in one go, which hit token limits on longer episodes. I had to implement a chunking strategy for episodes longer than 45 minutes, summarizing each chunk before combining them into the final show notes. It added a bit of complexity to the Worker, but it made the tool reliable for long-form content.

If you're struggling with the pre-publishing checklist and want to see how structured prompting changes the output quality, I've made the core title logic available to the community. You can try the free Podcast Title Generator at https://podcrisp.com/free-tools/title-generator to brainstorm some options for your next episode.

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