The RSS decision that changed how we built Podcastr

The fragmentation problem nobody talks about

When we started building Podcastr, the podcasting landscape looked like this: creators would record in one app, edit in another, generate clips for Instagram in a third, and then use a fourth tool entirely just to push their show to Spotify and Apple Podcasts. Some were paying £100, £150, sometimes more per month across different subscriptions. The math didn't work. The workflow didn't work. And honestly, the creator experience was broken.

What surprised us during early user interviews was that nobody complained about any single tool being bad. Riverside did remote recording brilliantly. Descript's transcription was solid. Buzzsprout handled distribution. The problem wasn't quality. The problem was friction. Every tool lived in its own silo. Export audio from A, import to B, download the transcription from B, paste it into C, then finally upload the whole thing to your distribution service. Repeat this for every episode.

That's when we realised RSS 2.0 wasn't just a technical detail. It was the connective tissue the industry was missing.

Why RSS 2.0 mattered more than it sounded

For people outside podcasting, RSS might sound like technical scaffolding. But RSS 2.0 is the open standard that lets your podcast exist independently. It's the difference between owning your show and renting distribution rights from a platform.

Here's what actually matters: RSS 2.0 publishing means your episode metadata, audio files, transcripts, and artwork can move from Podcastr directly to Spotify, Apple Podcasts, and Google Podcasts with a single step. No exporting. No re-uploading. No waiting for syndication delays. When you hit publish in Podcastr, your show goes live everywhere within minutes.

The technical decision to build RSS 2.0 support into the core of Podcastr rather than treating it as an afterthought meant we had to think about metadata differently. Every transcription we generate, every show note we auto-create, every guest bio we store (especially through our NFC Guest Passport feature for Pro users) has to feed into a properly structured RSS feed. That constraint actually improved the entire product. It forced us to be intentional about data architecture from day one.

When Spotify changed their distribution requirements last year, we didn't scramble. Our RSS implementation was solid enough to adapt. That's not luck. That's what happens when you build the connective layer properly.

The moment it clicked

Three weeks into our beta period, a solo podcaster named Marcus recorded his first episode at 11 PM, hit publish at 11:15 PM, and woke up the next morning to see it live on Spotify, Apple, and Google simultaneously. He sent us a video message. In it, he was honestly just shocked. 'I pressed one button,' he said. 'One. Button.' He'd been using the old scattered-tools approach for eight months before finding Podcastr.

That's when we knew we'd made the right call. RSS 2.0 publishing wasn't a feature box to tick. It was the answer to a question creators didn't even know they were asking.

It also changed how we thought about adding features later. When we built our short-clip generator for social media, we made sure the metadata automatically fed back into your show notes. When we developed the integrated teleprompter in RecordView so you never lose your place mid-episode, we ensured the transcript it generated would be publication-ready within minutes. Every feature got designed with the end-to-end workflow in mind, not as a standalone tool. That's the RSS philosophy spreading through the whole product.

What it freed us to do

Building RSS 2.0 publishing as a core layer meant we could stop worrying about platform lock-in and start worrying about what actually mattered: making the recording, transcription, and content generation experience so good that creators didn't want to leave. Not because they couldn't, but because it just worked better here.

That's why the free tier includes RSS publishing. Three episodes, full access to publication on Spotify and the other major platforms. No paywall on distribution. We're betting that once creators see how smooth the entire Podcastr workflow is - from recording local and remote guests in multi-track quality, to OpenAI Whisper transcription, to auto-generated show notes, to publishing everything with one click - they'll stick around and upgrade to Creator or Pro for the bells and whistles.

The Pro tier adds the NFC Guest Passport (tap your guest's phone to auto-populate their bio and socials directly into show notes), advanced AI features, and better clip generation. Studio tier is built for teams and agencies running white-label shows. But the backbone that makes all of that work cleanly? That's the RSS publishing layer we fought to get right.

The thing we almost got wrong

We nearly made the mistake of positioning Podcastr as 'RSS publishing plus recording.' Instead, we learned early that it had to be the opposite. Recording, transcription, and content creation come first. Publishing is the finish line, not the feature. When that beta tester asked 'Why can't it just go there?', she wasn't asking for an RSS feed editor. She was asking for the entire friction to disappear.

That reframing changed everything about how we talk about the product and how we prioritise development. A lot of ambitious features get proposed. But we keep coming back to the same question: does this serve the end-to-end creator workflow? Does it move us closer to that moment where someone presses publish once and their show is everywhere they need it to be?

Some of our best work has been saying no to things that looked good in isolation but broke the simplicity of that core promise.