OTT-App-Kosten: Die Aufschlüsselung pro Plattform für 2026

Wichtigste Erkenntnisse in 60 Sekunden

1. Ein OTT-Produkt ist nicht eine App. Es ist ein Portfolio von Apps für Mobile, Web, Smart-TV und Set-Top-Boxen, jede mit einer anderen Sprache, einem anderen Zertifizierungsweg und einem anderen Kostenprofil.
2. Die Spanne zwischen der günstigsten Oberfläche (Web) und der restriktivsten (Roku) kann allein bei den Arbeitskosten drei zu eins betragen, noch bevor Zertifizierungszeiträume dazukommen.
3. Cross-Platform-Tooling hat sich verbessert, aber jeder Framework-Weg hängt davon ab, dass ein Anbieter ihn weiter unterstützt. Amazon hat gerade gezeigt, wie schnell diese Annahme ablaufen kann.
4. Native zahlt sich in der Medienschicht aus. Bei Live-Sport sind die letzten 10 % nativ-äquivalenten Verhaltens genau die 10 %, auf die es ankommt.
5. Beginnen Sie damit, die Oberflächen aufzulisten, die Ihr Publikum tatsächlich nutzt, und kalkulieren Sie dann jede einzeln.

Der Vorstand genehmigte ein Budget für „die App“. Im Singular.

Ich saß einige Wochen später mit im Raum, als der technische Direktor durchging, was „die App“ tatsächlich bedeutete: iOS, Android, Web, Samsung, LG, Fire TV, Roku und ein Apple-TV-Build, den jemand im Vertrieb bereits einem Sponsor versprochen hatte. Acht Oberflächen. Vier verschiedene Programmiersprachen. Drei separate Zertifizierungsprozesse mit drei separaten Warteschlangen.

Niemand hatte den Vorstand belogen. Die Frage war schlicht im Singular gestellt worden, und eine Singular-Antwort kam zurück: eine Zahl, für eine App, als wäre ein Streaming-Produkt ein einzelnes Ding statt eine Ansammlung von Dingen. Die tatsächlichen OTT-App-Entwicklungskosten bestanden aus acht Zahlen, und niemand hatte danach gefragt, sie getrennt zu betrachten. Das Budget lag um ein Vielfaches daneben.

Das Budget lag um ein Vielfaches daneben.

Drei Fragen sind wichtiger als die Gesamtsumme: was jede Oberfläche kostet, welche Sie dieses Jahr wirklich brauchen, und wer die Schicht kontrolliert, in der Live-Video entweder funktioniert oder Sie blamiert.

Die OTT-Plattform-Kostenaufschlüsselung, die Vorstände meist übersehen

Die meisten Organisationen starten mit einer einzigen Zahl für „das Frontend“. Diese Zahl liegt fast immer daneben (nicht um 20 %, sondern um den Faktor drei oder vier), weil niemand die Frage nach Oberflächen aufgeschlüsselt hat.

Ein OTT-Produkt ist nicht eine App. Es ist ein Portfolio von Apps für Mobile, Web, Smart-TV und Set-Top-Boxen, jede mit einer anderen Sprache, einem anderen Zertifizierungsweg und einem anderen Kostenprofil. Die Spanne bei den OTT-Plattform-Entwicklungskosten zwischen der günstigsten Oberfläche (Web) und der restriktivsten (Roku) kann allein bei den Arbeitskosten drei zu eins betragen, noch bevor Zertifizierungszeiträume berücksichtigt werden.

Um die Kosten der OTT-App-Entwicklung zu verstehen, beginnt man mit einer Frage: Für welche Oberflächen bauen Sie? Hier sehen Sie, was pro Oberfläche tatsächlich den Ausschlag gibt:

Über den Build selbst hinaus zählen zwei Zahlen. Die Wartung kostet jährlich 15–20 % der Build-Kosten. Und der ursprüngliche Build macht typischerweise nur etwa 30 % Ihrer Ausgaben im ersten Jahr aus, sobald Infrastruktur, DRM und Datenübertragung mitgezählt werden. Das Frontend ist der sichtbare Teil der Rechnung, nicht die ganze.

Beginnen Sie damit, die Oberflächen aufzulisten, die Ihr Publikum tatsächlich nutzt, und kalkulieren Sie dann jede einzeln.

Warum dieselbe App auf einer Plattform dreimal so viel kostet wie auf einer anderen

Weil die Plattform Ihre Sprache bestimmt, und zwei von ihnen bestimmen sie schlecht.

Sechs Fernseh-Betriebssysteme, aber nur drei Programmiermodelle. Samsung, LG und Hisense betreiben HTML5-Web-Apps. Android TV und das ältere Fire OS laufen mit Kotlin gegen ExoPlayer. Roku nutzt BrightScript, eine proprietäre Sprache, die Roku in den 2000er-Jahren erfunden hat, auf einem Scene-Graph-UI-Framework, das keine andere Plattform verwendet. So gruppiert brauchen sechs Plattformen drei oder vier Player-Implementierungen statt sechs. Das ist die nützlichste Kosteneinsicht für alle, die dieses Budget planen.

Bei Roku gehen Schätzungen am häufigsten schief (wir haben separat darüber geschrieben, wie man bessere TV-Apps für Roku baut, aber die Kostengeschichte beginnt hier). Es gibt keinen Kotlin-Weg, keinen JavaScript-Weg, kein Ausweichen auf ein Framework: BrightScript oder nichts. Die Zertifizierung dauert vier bis acht Wochen und testet gegen Hardware einschließlich des Einstiegsmodells Express, das mit einem Single-Core-Prozessor unter 1 GHz und 256 MB RAM läuft. Eine Oberfläche, die auf einem Roku Ultra flüssig läuft und auf einem Express Frames verliert, wird abgelehnt. Das ist keine schwierige App. Es ist eine anders schwierige App, und sie braucht Menschen, die schon einmal eine ausgeliefert haben.

Es gibt keinen Kotlin-Weg, keinen JavaScript-Weg, kein Ausweichen auf ein Framework: BrightScript oder nichts.

Können wir es nicht einfach einmal bauen und überall ausliefern?

Teilweise. Im Oktober 2025 zeigte Amazon genau, was diese Wette kostet, wenn sie schiefgeht.

Fire TV war früher ein Fork von Android, sodass eine Fire-TV-App eine Android-App mit einem anderen Store-Eintrag war. Dann begann Amazon, Fire OS durch Vega OS zu ersetzen, ein Linux-basiertes System, das auf React Native und Webtechnologie aufbaut. Eine Android-APK läuft darauf nicht. Bis Januar 2026 hatte Amazon bestätigt, dass alle künftigen Fire TV Sticks mit Vega ausgeliefert werden, was bedeutet, dass jeder Sender, der auf neuer Amazon-Hardware präsent sein möchte, nun eine komplett neue App bauen muss.

Beachten Sie die Ironie, denn sie ist lehrreich: Das „plattformübergreifende“ Framework ist jetzt auf einer Oberfläche der verpflichtend native Stack. Wir haben diesen Wandel (zusammen mit FAST-Kanälen und der Ad-Tier-Ökonomie) in unseren OTT-Trends für 2026 angesprochen. Das ist das zentrale Argument gegen eine Strategie, die auf eine einzige Abstraktion setzt. Cross-Platform-Tooling hat sich verbessert. React-Native-Teams berichten von 60–80 % Codewiederverwendung über TV-Ziele hinweg, Samsung unterstützt Flutter über flutter-tizen, LG baut an einem webOS-Flutter-SDK. Aber jeder dieser Wege hängt davon ab, dass ein Anbieter sich weiterhin dafür entscheidet, ihn zu unterstützen, und Amazon hat gerade gezeigt, wie schnell diese Annahme ablaufen kann.

Wenn sich die Plattform bewegt, bedeutet eine native Codebasis, dass Sie eine Oberfläche neu schreiben. Eine Framework-Abhängigkeit bedeutet, dass Sie darauf warten, dass jemand anderes aufholt, und Sie haben keine Kontrolle darüber, wann das geschieht oder ob es überhaupt geschieht.

Wo sich Native wirklich auszahlt

In der Medienschicht. Bei Live-Sport ist das das gesamte Produkt.

Nicht die Browse-Bildschirme und Rasteransichten sind der Ort, an dem Abstraktion schadet. Es ist die Wiedergabe. Jede harte Anforderung im Live-Sport liegt innerhalb von ein oder zwei API-Aufrufen des plattformeigenen Players: latenzarme Live-Kante, hardwaregestütztes DRM für Premium-Rechte, mehrere Audiospuren für Kommentarsprachen, Trickplay gegen ein rollierendes DVR-Fenster und adaptive Bitrate, die stabil bleibt, wenn 400.000 Menschen innerhalb derselben neunzig Sekunden zuschalten.

Native gibt Ihnen direkten Zugriff auf AVPlayer, ExoPlayer und AVPlay: denselben Stack, den wir beim Aufbau von Sport-Streaming-Erlebnissen verwenden. Eine plattformübergreifende Schicht gibt Ihnen einen Wrapper darum herum, und Wrapper hinken der Plattform um ein oder zwei Release-Zyklen hinterher. Diese Lücke ist bei einem Katalog von Drama-Boxsets unsichtbar und beim Anpfiff unerbittlich. Die Faustregel im Engineering (die letzten 10 % nativ-äquivalenten Verhaltens kosten am meisten) beschreibt zufällig genau die 10 %, von denen Live-Sport abhängt.

Die letzten 10 % nativ-äquivalenten Verhaltens kosten am meisten, und das sind genau die 10 %, von denen Live-Sport abhängt.

Welche Streaming-Plattform sollten Sie zuerst bauen?

Beginnen Sie dort, wo Ihre Watch-Time bereits liegt. Fügen Sie dann die Oberfläche hinzu, die Ihr Vertriebsteam versprochen hat. In dieser Reihenfolge.

Die regionale Verteilung zählt mehr als jede allgemeine Empfehlung. In den USA hält Roku rund 28 % der genutzten Fernseher und Samsungs Tizen etwa 23 %. Weltweit führen Android TV und Google TV mit 35–40 %, gefolgt von Tizen mit etwa 19–23 % und Roku mit knapp 10 %. In Europa dominieren Samsung und LG im Wohnzimmer, während Android TV bei Set-Top-Boxen der Betreiber eine bedeutende Rolle spielt.

Die richtige Reihenfolge hängt von Ihrem Publikum, Ihrem Content-Modell und davon ab, wo Ihre kommerziellen Verpflichtungen bereits liegen. Wir haben Sendern, Sportverbänden und D2C-Plattformen geholfen, das herauszufinden, und die Antwort fällt jedes Mal anders aus. Was ich aber nicht tun würde: alle acht Oberflächen im ersten Jahr kaufen. Bauen Sie drei davon richtig, instrumentieren Sie sie, und lassen Sie die tatsächliche Nutzung entscheiden, welche die vierte sein sollte. Welche drei Sie auch wählen: wie schnell Sie das nächste Feature über alle davon ausliefern können, zählt fast genauso viel wie welche drei Sie ausgewählt haben.

Bewerten Sie Ihre Budgetposition

Was kostet die Wartung einer OTT-App im zweiten Jahr?

Etwa 15–20 % der Build-Kosten jährlich, plus den langen Schwanz aus Zertifizierung und Firmware, den niemand in den Business Case einrechnet.

Jedes Modelljahr bringt neue Firmware-Varianten. Samsungs Tizen verhält sich je nach Modellreihe unterschiedlich; ältere LG-webOS-Geräte implementieren eine HLS-Revision aus dem Jahr 2014, was bedeutet, dass ein JavaScript-Player statt nativer Wiedergabe ausgeliefert werden muss. Roku verlangt eine erneute Zertifizierung. Apple und Google ändern ihre Store-Anforderungen. Eine Testmatrix, die nur die diesjährigen Flaggschiff-Fernseher abdeckt, testet nicht Ihr Publikum. Sie testet nur den Ausschnitt davon, der kürzlich einen Fernseher gekauft hat.

In diesem langen Schwanz entdecken viele Organisationen, dass sie einen Entwicklungspartner brauchen, nicht nur einen Anbieter, der baut und übergibt. Das Frontend ist ein Produkt, und es braucht dieselbe kontinuierliche Pflege wie die Inhalte, die es ausliefert. Die richtige Monetarisierungsstrategie ist ebenso wichtig: SVOD, AVOD oder hybrid: Jedes Modell verändert, was das Frontend unterstützen muss.

Wann ist Cross-Platform die richtige Wahl?

Wenn Ihr Katalog aus Long-Form-VOD besteht, Ihre Differenzierung über Inhalte statt über das Produkt läuft und Time-to-Market wichtiger ist als Wiedergabeleistung.

Das sage ich lieber offen, als so zu tun, als sei Native universell richtig. Wenn Sie eine einfache On-Demand-Bibliothek mit begrenztem Budget auf acht Oberflächen ausliefern, ist ein Framework mit 60–80 % Wiederverwendung ein vernünftiger Kompromiss. Die Wiederverwendung des Web-Stacks über Samsung, LG und Hisense hinweg ist effizient: Diese drei teilen sich ein Programmiermodell, ob Sie ein Framework nutzen oder nicht.

Aber wenn Sie Live-Rechte halten, wenn Latenz, DRM und Mehrfachaudio vertraglich vorgeschrieben statt nur wünschenswert sind, und wenn das Produkt sich differenzieren statt nur liefern soll, werden Sie in der Wiedergabeschicht ohnehin nativen Code schreiben. Besser, das von vornherein einzuplanen, als es an einem Samstag im Stadion herauszufinden.

Die Zahl, die Sie Ihrem Vorstand vorlegen sollten

Die tatsächlichen OTT-App-Entwicklungskosten sind die Kosten pro Oberfläche, multipliziert mit den Oberflächen, die Sie in drei Jahren noch selbst kontrollieren.

Der Sender aus der Eingangsgeschichte bekam schließlich eine realistische Zahl genehmigt. Was das Gespräch veränderte, war der Ersatz eines einzigen Worts durch eine Liste, und die Frage, welche Punkte auf dieser Liste ihr Publikum diese Saison tatsächlich bemerken würde.

Wenn Sie diese Liste gerade erstellen oder auf ein Budget blicken, das im Singular genehmigt wurde, sollten wir sprechen. Sie können auch erkunden, wie eine White-Label-OTT-Plattform die Build-vs.-Buy-Rechnung für einige dieser Oberflächen verändert, und falls ein White-Label-Anbieter bereits einen Teil Ihres Stacks besitzt, erfahren Sie hier, wie Sie erkennen, ob Ihre Roadmap noch Ihnen gehört. Wir sind außerdem im September beim IBC Amsterdam, Stand 5.F51, und das ist genau das Gespräch, das wir mit jedem Sender und Verband führen, der vorbeikommt.

Häufig gestellte Fragen

Wie viel kostet es, eine OTT-App für eine Plattform zu bauen?

Die OTT-App-Entwicklungskosten für eine einzelne Plattform hängen davon ab, für welche Oberfläche Sie bauen. Ein Web-Player ist die günstigste Oberfläche; eine Roku-App, in BrightScript für Low-End-Hardware gebaut, mit einem 4–8-wöchigen Zertifizierungszyklus, ist die teuerste. Die Spanne kann allein bei den Entwicklungskosten drei zu eins betragen, noch bevor Sie DRM-Lizenzen, Infrastruktur und Zertifizierungsgebühren berücksichtigen. Wenn Sie fragen, wie viel es kostet, eine OTT-Plattform zu bauen, lautet die Antwort: Fragen Sie stattdessen, wie viel jede Oberfläche kostet und welche drei Sie zuerst brauchen.

Warum ist die Entwicklung für Roku so viel teurer als für andere TV-Plattformen?

BrightScript. Es ist eine proprietäre Sprache, die nur auf Roku läuft, auf einem Scene-Graph-UI-Framework, das keine andere Plattform verwendet. Es gibt keinen JavaScript-Weg, keinen Kotlin-Weg, kein plattformübergreifendes Ausweichen. Die Zertifizierung testet gegen Hardware einschließlich des Einstiegsmodells Express mit einem Prozessor unter 1 GHz und 256 MB RAM, weshalb Performance-Tuning zwingend erforderlich ist. Die Kombination aus einer einzigartigen Sprache, eingeschränkter Hardware und einer 4–8-wöchigen Zertifizierungswarteschlange macht Roku zur teuersten Connected-TV-Oberfläche in Entwicklung und Wartung.

Sollte ich eine native OTT-App bauen oder ein plattformübergreifendes Framework verwenden?

Das hängt von Ihrem Content-Modell ab. Wenn Sie Long-Form-VOD ausliefern und Time-to-Market am wichtigsten ist, ist ein plattformübergreifendes Framework mit 60–80 % Codewiederverwendung ein vernünftiger Kompromiss. Wenn Sie Live-Sportrechte halten, bei denen latenzarme Wiedergabe, Hardware-DRM, Mehrfachaudio und adaptive Bitrate unter gleichzeitigen Lastspitzen vertraglich vorgeschrieben sind, werden Sie in der Wiedergabeschicht ohnehin nativen Code schreiben. Die Frage ist, ob Sie das von vornherein einplanen oder es am Spieltag herausfinden.

Was ist mit Amazon Fire TV und Vega OS passiert?

Amazon begann, Fire OS (einen Android-Fork) durch Vega OS zu ersetzen, ein Linux-basiertes System, das auf React Native und Webtechnologie aufbaut. Eine Android-APK läuft auf Vega nicht. Bis Januar 2026 bestätigte Amazon, dass alle künftigen Fire TV Sticks mit Vega ausgeliefert werden, was bedeutet, dass jeder Sender, der auf neuer Amazon-Hardware präsent sein möchte, nun eine komplett neue App bauen muss, selbst wenn er bereits eine Fire-TV-App auf dem alten Android-basierten System hatte.

Auf wie vielen OTT-Plattformen sollte ich im ersten Jahr starten?

Auf dreien, richtig gebaut und instrumentiert. Starten Sie dort, wo Ihre Watch-Time bereits liegt, fügen Sie die Oberfläche hinzu, die Ihr Vertriebsteam versprochen hat, und lassen Sie dann echte Nutzungsdaten entscheiden, welche die vierte sein sollte. Alle acht Oberflächen im ersten Jahr zu kaufen, verteilt Budget und QA zu dünn und führt meist dazu, dass keine davon gut genug funktioniert, um Abonnenten über die erste Saison zu halten.

Wie viel kostet eine Streaming-App?

Die Kosten für die Entwicklung einer Streaming-App hängen davon ab, was Sie unter „einer App" verstehen. Meinen Sie einen einzelnen webbasierten Player, ist das die günstigste Oberfläche. Meinen Sie ein vollständiges Multi-Plattform-Streaming-Produkt (iOS, Android, Web, Smart-TVs, Set-Top-Boxen), liegt die Gesamtsumme typischerweise beim Drei- bis Fünffachen dessen, was die meisten Teams für eine einzelne Oberfläche budgetieren. Infrastruktur, DRM-Lizenzierung, Content-Delivery und laufende Wartung verursachen über den Frontend-Build hinaus weitere Kosten. Der sinnvollste Ausgangspunkt ist, die Plattformen aufzulisten, die Ihr Publikum tatsächlich nutzt, und jede einzeln zu kalkulieren.

Was kostet die Entwicklung einer Smart-TV-App im Vergleich zu Mobile?

Die Entwicklung von Smart-TV-Apps (Samsung Tizen, LG webOS, Android TV, Roku) kostet pro Oberfläche typischerweise mehr als bei Mobile (iOS oder Android). Die Gründe sind Fragmentierung nach Modelljahr, proprietäre SDKs (BrightScript bei Roku, AVPlay bei Samsung) und Zertifizierungszeiträume, die pro Release vier bis acht Wochen hinzufügen können. Ein gemeinsames Designsystem über iOS und Android hinweg senkt die Kosten für den zweiten mobilen Build, aber jede TV-Oberfläche ist praktisch ein separater Build mit eigener Sprache, eigener Testmatrix und eigenem Einreichungsprozess.