Eine Podcast-Hosting-Plattform mit KI bauen: RSS-Feeds, Speicher und bezahlte Abos

Kurzantwort

Ein Podcast-Host ist im Kern nur ein RSS-Feed, ein Datei-Speicher, der Audio ohne Ruckeln streamt, und ein Mechanismus, um Downloads ehrlich zu zählen — verkleidet als eigenständiges Produkt. Nichts davon erfordert, dass man sich bei Libsyn oder Buzzsprout einmietet. Ein KI-App-Builder wie Greta kann die eigentliche Feed-Generierung, den Speicher und die Subscriber-Gating-Logik als App scaffolden, die Ihnen selbst gehört — keine Preisstufe pro Download, keine spätere Migrationsqual.

Warum wird das Mieten eines Podcast-Hosts irgendwann zum Problem?

Jede gehostete Podcast-Plattform verkauft Ihnen denselben Deal: Bequemlichkeit jetzt, eine Obergrenze später. Buzzsprout deckelt Sie nach monatlichen Downloads. Libsyn knausert bei Speicher und Analyse-Tiefe. Transistors „Unlimited"-Pläne sperren bezahlte Abos trotzdem hinter ihrer höchsten Stufe. Für eine Hobby-Show ist das in Ordnung. Weniger in Ordnung, sobald Sie dynamische Werbe-Einblendung, exklusive Bonusfolgen für zahlende Hörer betreiben oder für ein Sponsoring-Deck rohe Download-Daten brauchen statt des Diagramms, das der Host Ihnen gerade zeigen möchte.

Die eigentliche Lock-in-Falle sind nicht die Audiodateien — die können Sie jederzeit neu hochladen. Es ist die RSS-Feed-URL. Genau diese URL haben Apple Podcasts, Spotify und jede Podcast-App auf dem Telefon eines Hörers bereits abonniert. Wechseln Sie den Host, müssen Sie entweder den alten Feed umleiten (manche Hosts erlauben das, manche nicht) oder Sie verlieren Ihre Abonnentenbasis und starten bei null Downloads. Ich habe Shows erlebt, die den Plattformwechsel ein ganzes Jahr aufgeschoben haben — nur weil niemand diese URL anfassen wollte.

Das GUID-Problem, das vorher niemand erklärt

Jede Episode in einem RSS-Feed braucht einen stabilen, eindeutigen <guid>-Tag. Podcast-Apps nutzen ihn, um zu entscheiden, ob eine Episode neu oder bereits heruntergeladen ist. Wechseln Sie den Host unachtsam und generieren die GUIDs dabei neu, denkt jede App Ihrer Hörer, alle 200 Altfolgen wären gerade auf einmal erschienen. Das ist keine Theorie — genau das passiert Shows, die migrieren, ohne vorher ihre exakte GUID-Historie zu exportieren.

Was muss unter der Haube eines Podcast-Hosts tatsächlich funktionieren?

Entfernt man die Marketing-Seite, besteht ein Podcast-Host aus vier Infrastruktur-Teilen, nicht aus einem. Die RSS-Feed-Generierung muss der RSS-2.0-Spezifikation plus Apples iTunes-Namespace-Tags (itunes:duration, itunes:episode, itunes:explicit) so genau folgen, dass Apples Feed-Validator sie nicht ablehnt. Der Audio-Speicher muss Dateien schnell ausliefern und Byte-Range-Requests unterstützen, damit ein Hörer zu Minute 40 einer zweistündigen Episode springen kann, ohne die ersten 39 Minuten erneut herunterzuladen. Die Analytics müssen etwas näher an einem echten Download zählen als einen rohen HTTP-Hit — die Messrichtlinien des IAB für Podcasts deduplizieren innerhalb eines rollierenden Zeitfensters nach User-Agent und IP, genau weil Podcast-Apps dieselbe Datei für Auto-Downloads und Teil-Abrufe mehrfach anfragen. Und Feeds nur für Abonnenten brauchen eine private RSS-URL mit einem nicht erratbaren Token — RSS selbst hat schließlich kein Login-System.

Keines dieser vier Probleme ist exotisch. Es sind einfach Probleme, bei denen die meisten Leute annehmen, dass man eine spezialisierte SaaS-Lösung braucht, um sie zu lösen.

Wie wird das mit Greta tatsächlich gebaut?

Greta scaffoldet das als normale Next.js-App mit einer Prisma-gestützten Postgres-Datenbank, die sich sauber auf Podcast-Hosting abbilden lässt. Eine Show-, eine Episode- und eine Subscriber-Tabelle decken den Großteil des Datenmodells ab — Episode-Zeilen halten die Audio-Datei-URL, die Dauer, das Veröffentlichungsdatum und eine stabile GUID, die einmal bei der Erstellung generiert und danach nie mehr angefasst wird. Der Feed selbst ist eine einzige Next.js-API-Route, etwa app/api/feed/[showId]/route.xml/route.ts, die veröffentlichte Episoden abfragt und XML dynamisch rendert statt einer statischen Datei, die bei jeder Veröffentlichung neu erzeugt werden müsste.

Audiodateien liegen in Object Storage — Supabase Storage oder S3 hinter einem CDN — und werden mit Range-Request-Unterstützung ausgeliefert, damit das Scrubben so funktioniert, wie Hörer es von Apple Podcasts oder Spotify gewohnt sind. Bezahlte Feeds bekommen ihre eigene Route mit Token-Prüfung: /api/feed/[showId]/[token]/route.xml, wobei das Token auf eine Subscriber-Zeile verweist statt auf etwas, das sich aus der öffentlichen URL erraten lässt. Ein Stripe-Subscription-Webhook ist es, der diese Subscriber-Zeile überhaupt erst aktiv schaltet — dasselbe Muster, mit dem Sie einen bezahlten Newsletter absichern würden, nur eben auf eine Feed-URL statt auf einen Artikel gerichtet. Das ist der gesamte Mechanismus, für den bezahlte Podcast-Plattformen einen Aufpreis verlangen: ein Lookup und eine Bedingung.

Was braucht Hörer-Analytics tatsächlich, wenn man sie selbst baut?

Ehrlich gesagt eher Disziplin als Code. Eine Downloads-Tabelle mit Zeitstempel, Episode-ID und gehashter IP bringt Sie fast schon ans Ziel. Der Trick liegt in der korrekten Deduplizierung: Podcast-Apps stellen beim Abspielen, Pausieren und Fortsetzen oft mehrere Teil-Anfragen für dieselbe Episode — zählt man jede davon als separaten Download, blähen sich die Zahlen auf, die Sie irgendwann einem Sponsor gegenüber rechtfertigen müssen. Bauen Sie die Dedup-Logik einmal richtig (dieselbe IP und derselbe User-Agent innerhalb eines 24-Stunden-Fensters zählen als ein Download), und Sie erhalten Zahlen, hinter denen Sie in einem Sponsoring-Gespräch stehen können — plus die Möglichkeit, alles abzufragen: Downloads nach Episode, nach Tag, nach Region, ohne auf die Export-Funktion eines Hosts warten zu müssen.

Host mieten vs. eigene Plattform bauen

FAQ

Muss ich einen RSS-Parser von Grund auf schreiben? Nein — RSS 2.0 plus der iTunes-Namespace ist eine gut dokumentierte XML-Spezifikation, kein Reverse-Engineering-Projekt. Sie generieren XML aus einer Datenbankabfrage — das ist ein Template-Problem, kein Parsing-Problem.

Akzeptieren Apple Podcasts und Spotify wirklich einen selbst gebauten Feed? Ja. Beide Plattformen interessiert nur, ob der Feed gegen die Spezifikation validiert — sie haben keine Möglichkeit zu erkennen, ob er von Buzzsprout oder Ihrer eigenen Next.js-Route stammt.

Wie handhabe ich dynamische Werbe-Einblendung ohne das eingebaute Tool eines Hosts? Speichern Sie Werbeslots als Zeitstempel pro Episode und binden Sie sie entweder direkt bei der Veröffentlichung in die Audiodatei ein oder liefern Sie basierend auf einem Query-Parameter der Streaming-URL einen leicht unterschiedlichen Pre-Roll aus. Das ist mehr Aufwand als der One-Click-Schalter eines Hosts, aber Sie zahlen dafür auch keine Umsatzbeteiligung.

Was passiert mit meiner bestehenden Show, wenn ich migriere? Exportieren Sie zuerst die exakte GUID jeder Episode von Ihrem aktuellen Host — das ist der eine nicht verhandelbare Schritt. Erstellen Sie den Feed mit identischen GUIDs neu, und die Apps Ihrer Hörer behandeln ihn als dieselbe, fortlaufende Show — nicht als eine neue, die bei Episode eins beginnt.

Fazit

Ein Podcast-Host war nie wirklich ein eigenständiges Produkt — er ist eine dünne, profitable Schicht über einem RSS-Feed, einem Dateiserver und einem Download-Zähler. Sobald man das erkennt, fühlt sich das Mieten optional statt notwendig an — besonders sobald dynamische Werbung oder bezahlte Abonnenten-Feeds tatsächlich Teil des Plans sind.

Starten Sie noch heute den Bau Ihrer Podcast-Plattform mit Greta.