Im Frühjahr 2026 haben wir begonnen, podlet zu bauen. Heute, ein gutes halbes Jahr später, ist die Plattform noch nicht live - aber an einem Punkt, an dem unser Ziel, im zweiten Quartal 2027 online zu gehen, realistisch ist. Was dazwischenliegt, ist nicht der gerade Weg, den man sich vorstellt, wenn man ein Produkt ankündigt - sondern der kurvenreiche, der wirklich passiert.
Dieser Beitrag ist keine Erfolgsgeschichte. Er ist eine ehrliche Bestandsaufnahme: Was wir uns gedacht haben, was wir falsch gemacht haben, was schließlich funktioniert hat - und was wir beim nächsten Produkt anders angehen werden.
Die Lücke, die wir gesehen haben
Österreichische Podcaster haben es nicht leicht. Internationale Plattformen wie Spotify for Podcasters, Buzzsprout oder Anchor lösen das technische Grundproblem gut: Upload, RSS-Feed, Distribution auf die großen Verzeichnisse. Aber sie lösen nicht das Problem dahinter - wie baut ein österreichischer Podcaster eine Community auf, findet seine Zuhörer im deutschsprachigen Raum, und wird in einem lokalen Kontext sichtbar?
Wir haben selbst Podcast-Projekte begleitet - als Berater und als Produzenten. Das Grundproblem war jedes Mal dasselbe: Das Hochladen funktioniert. Aber Community-Aufbau, lokale Sichtbarkeit und die Verbindung zwischen Podcaster und Publikum funktionieren auf globalen Plattformen nicht gut für kleine, deutschsprachige, regional verwurzelte Formate. Spotify interessiert sich für ein Nischen-Podcast über Niederösterreicher Winzer herzlich wenig - der Algorithmus kennt ihn nicht, und das bleibt so.
Also haben wir entschieden, selbst eine Plattform zu bauen. Das war, aus heutiger Sicht, sowohl die richtige Entscheidung als auch eine deutlich unterschätzte.
Die ersten Entscheidungen
Technologie-Stack
Wir haben uns früh für Next.js als Frontend-Framework entschieden, mit PostgreSQL als Datenbank und S3-kompatiblem Objekt-Storage für die Audio-Dateien. Klingt nach einer Standard-Entscheidung - und das war sie auch. Aber Standard war hier richtig. Wir kennen diesen Stack gut, können schnell damit arbeiten, und er skaliert, wenn es nötig wird.
Was wir nicht getan haben: uns wochenlang zwischen Technologien zu vergleichen. Der Stack war nach zwei Tagen entschieden. Im Nachhinein eine der besten Entscheidungen des Projekts.
RSS-Kompatibilität als Pflicht
Podcasting lebt von RSS. Wer das ignoriert oder nachträglich einfügt, baut auf wackeligem Fundament - und verliert das Vertrauen aller Podcaster, die ihren Feed bereits auf anderen Plattformen verteilt haben. Wir haben RSS-Output von Tag eins mitgedacht: Als Core-Feature, nicht als nachgelagerte Anforderung. Jeder Podcast auf podlet bekommt einen vollständigen, iTunes-kompatiblen RSS-Feed, der auf allen großen Verzeichnissen funktioniert.
Mobile First
Podcast-Hörer sind überwiegend mobil. Das ist keine Insights-Erkenntnis aus einer Studie - das ist Alltagsbeobachtung. Also haben wir von Anfang an mobile Layouts priorisiert. Desktop ist wichtig, aber wenn die mobile Erfahrung nicht stimmt, verliert man den Großteil des Publikums, bevor es überhaupt anfängt.
Was gründlich schief lief
Unsere erste Version war ein Lehrstück in Over-Engineering. Wir wollten alles gleichzeitig bauen.
Eine Plattform für Hörer und Podcaster. Ein CMS für Shownotes mit Formatierungsoptionen. Kapitel-Marker im Audio-Player. Ein Empfehlungssystem auf Basis von Hörgewohnheiten. Kommentarfunktion mit Moderations-Tools. Ein Analytics-Dashboard für Podcaster. Newsletter-Integration. Eine Suchfunktion über alle Inhalte.
Vier Monate Entwicklungszeit später hatten wir eine technisch beeindruckende, aber kaum nutzbare erste Version. Zu komplex, zu viele Moving Parts, zu wenig echte Nutzertests. Die interne Demonstration vor sechs Pilot-Podcastern war ernüchternd: Die Features, auf die wir stolz waren - das Empfehlungssystem, die Kapitel-Marker, das Analytics-Dashboard - wurden fast gar nicht benutzt. Das, was fehlte, waren Grundfunktionen, die wir als selbstverständlich vorausgesetzt hatten. Der Upload-Prozess war zu umständlich. Die Podcast-Seite sah gut aus, aber die Audioplayer-Performance war auf mobilen Geräten miserabel. Das Erstellen eines Accounts fühlte sich wie Bürokratie an.
Wir haben vier Monate daran gearbeitet, Probleme zu lösen, die unsere Nutzer noch gar nicht hatten.
Wir haben die erste Version weitgehend weggeworfen. Nicht alles - der Code war nicht schlecht, und Teile der Infrastruktur haben wir mitgenommen. Aber die Produktarchitektur haben wir neu aufgesetzt.
Das war schmerzhaft. Vier Monate Arbeit, für ein Team, das nebenbei laufende Kundenprojekte betreut, sind viel. Aber es war die richtige Entscheidung. Eine falsche erste Version ist teurer als kein Produkt.
Was jetzt funktioniert
Version zwei war radikal einfacher. Upload, RSS-Feed, öffentliche Podcast-Seite mit integriertem Player. Das war es. Kein Empfehlungssystem, keine Kommentare, kein komplexes Analytics-Dashboard. Nur das Kern-Erlebnis: Ein Podcaster kann seinen Podcast auf podlet hochladen, bekommt eine saubere, professionell aussehende Seite und einen RSS-Feed, der auf Spotify, Apple Podcasts und überall sonst funktioniert. Genau dieser Kern steht heute stabil.
Unsere Pilot-Podcaster binden wir seither sehr direkt in die Entwicklung ein. Nicht mit langen Umfragen, sondern mit echten Gesprächen: Was nervt dich? Was fehlt? Was nutzt du tatsächlich? Die Antworten waren überraschend konsistent und überraschend simpel. Die Leute wollten eine schnelle Möglichkeit, ihren Podcast ansprechend zu präsentieren - ohne technischen Aufwand, ohne monatelange Einrichtung, ohne ein Studium in Audio-Hosting zu absolvieren.
Kurze Iterationen machen den Rest. Alle zwei bis drei Wochen bekommt die Pilotgruppe eine neue Testversion mit einer konkreten Verbesserung: besserer Upload-Flow, verbesserte Player-Performance auf iOS, einfachere Shownotes-Formatierung. Keine großen Versprechen, sondern kontinuierliches Verbessern auf Basis von echtem Feedback.
Was wir beim nächsten Produkt anders machen würden
Früher in echte Hände, mit weniger Features
Der Punkt, an dem echte Nutzer ein Produkt sinnvoll testen können, ist viel früher erreicht, als man glaubt. Wir hätten podlet nach sechs Wochen mit einem minimalen Feature-Set an die Pilotgruppe geben sollen - Upload, RSS, Seite - und dann von ihr lernen sollen. Stattdessen haben wir vier Monate in eine Version investiert, die wir dann weggeworfen haben. Der Zeitunterschied zwischen "fertig" und "gut genug für erste echte Nutzer" ist kleiner als man denkt.
Nutzer fragen, nicht Annahmen machen
Wir haben in der ersten Version Entscheidungen getroffen, die auf unseren eigenen Präferenzen als Podcaster basierten. Das Empfehlungssystem war eine Funktion, die wir selbst als Hörer gut gefunden hätten. Unsere Zielgruppe - österreichische Podcaster, viele davon Einsteiger oder kleine Betriebe - hatte ganz andere Prioritäten. Nutzer sind nicht wie du. Das ist keine Kritik - das ist die Realität von Produktentwicklung.
Technische Schulden bewusst eingehen
Nicht alle technischen Schulden sind gleich. Manche sind echte Investitionspflichten, die man früh zahlen sollte - Sicherheit, Datenschutz, grundlegende Skalierbarkeit. Andere sind Optionen, die man sich offenlässt, weil man noch nicht weiß, welche Richtung das Produkt nimmt. In der ersten Version haben wir überall auf Perfektion gesetzt - bei Dingen, von denen wir noch gar nicht wussten, ob sie relevant werden. Das nächste Mal würden wir bewusster zwischen beiden Kategorien trennen.
Kleinere Definition von MVP
Was wir als MVP bezeichnet haben, war immer noch zu groß. Die Faustregel, die wir uns für das nächste Produkt vorgenommen haben: Wenn es nicht schmerzhaft klein wirkt, ist es noch nicht klein genug. Ein echter MVP sollte einen echten Nutzer in einer echten Situation durch eine echte Aufgabe führen. Alles andere ist Bonus - und Bonus kommt nach dem Launch, nicht davor.
Der Weg zum Launch im zweiten Quartal 2027
podlet ist noch nicht live. Aber der Kern aus Upload, RSS-Feed und Podcast-Seite steht, die Pilot-Podcaster arbeiten damit, und die offenen Punkte bis zum Start sind bekannt und überschaubar. Deshalb halten wir das zweite Quartal 2027 als Termin für den Launch für realistisch. Bis dahin gilt, was wir in den letzten Monaten gelernt haben: kleine Schritte, echtes Feedback, keine Features auf Vorrat.
Ob wir das Projekt ein zweites Mal genauso aufziehen würden? Nein. Wir würden früher loslassen, weniger annehmen, öfter fragen. Aber den Lernweg würden wir nicht missen - er hat uns zu einem besseren Verständnis geführt, wie Produkte wirklich entstehen: nicht durch Planung, sondern durch Iteration.
