Wie lange dauert es, ein Feature auf Ihrer Streaming-Plattform zu veröffentlichen?

Wichtigste Erkenntnisse in 60 Sekunden

Die entscheidende Kennzahl nach dem Launch ist die Feature Velocity: wie lange eine Funktion benötigt, um von der internen Genehmigung bis zum Bildschirm eines Abonnenten zu gelangen.
Zwei Fragen messen sie – Deployment-Frequenz und Lead Time. Beide können Sie noch heute Nachmittag stellen.
Auf einer White-label-Plattform gehört Ihr Release-Zeitplan dem Anbieter. Bei einem Custom Build gehört er Ihnen.
Jedes Gerät, das Sie hinzufügen, vergrößert den Unterschied zwischen Shared-Component- und Separate-Codebase-Architekturen.
Der Broadcaster, der am schnellsten gestartet ist, wird oft zum langsamsten bei der Veröffentlichung – die Velocity Inversion.

6 Wochen im Kalender. 8 Wochen im Angebot.

Das war das ganze Problem, und es passte in zwei Zahlen. Ein Broadcaster, mit dem ich zusammenarbeite, musste es Zuschauern ermöglichen, bei einem Live-Stream zwischen zwei Kommentarsprachen zu wählen – eine Änderung, die bei einem modernen Stack eine Konfigurationsentscheidung ist und in Tagen gemessen wird. Ihr White-label-Anbieter antwortete mit 8 Wochen. Das Rechtsfenster für diese Übertragung öffnete sich in sechs.

Also lief das Spiel in einer Sprache. Das Publikum, für das es konzipiert worden war, schaute es stattdessen auf der App eines Mitbewerbers, und als die Funktion technisch verfügbar war, war das Spiel, das sie gerechtfertigt hatte, bereits gespielt worden.

Niemand in dieser Geschichte hat etwas Leichtfertiges getan. Die Anforderung war vernünftig, die Schätzung des Anbieters war wahrscheinlich ehrlich, und der Technikdirektor hatte sie in dem Moment genehmigt, als sie auf seinem Schreibtisch landete. Er fand einfach heraus – im denkbar schlechtesten Moment –, dass die Uhr nie seine war.

„Jemand innerhalb des Broadcasters sagt Ja, und entdeckt dann, wie lange Ja tatsächlich dauert, wenn der Zeitplan jemand anderem gehört.“

Ich habe dieselbe Struktur in Dutzenden von Projekten wiederholt gesehen. Die Details sind nie zweimal gleich. Offline-Downloads auf einem Gerätetyp. Eine Wettintegration, die gegen ein Rechtsfenster antritt. Eine Zahlungsmethode, an die niemand gedacht hatte, bis die App in einem neuen Markt live war. Aber der Moment ist jedes Mal identisch: Jemand innerhalb des Broadcasters sagt Ja, und entdeckt dann, wie lange Ja tatsächlich dauert, wenn der Zeitplan jemand anderem gehört.

Warum die Launch-Geschwindigkeit die falsche Kennzahl für Ihre OTT-Plattform ist

Weil Sie bereits gestartet sind.

Die Branche spricht immer noch über „Time to Market“, als ob es die Launch-Geschwindigkeit bedeutete – wie schnell eine App 5 Stores auf allen Geräten erreicht. Nach diesem Maßstab gewinnt White-label eindeutig, und die Beweise sind schwer zu widerlegen: 6 bis 12 Wochen vom Vertrag bis zur Live-Schaltung, einschließlich Branding-Anpassung.

Aber die meisten europäischen Streaming-Betreiber sind vor 2 bis 4 Jahren live gegangen. Dieses Rennen ist beendet, und niemand wertet es mehr. Die Zahl, die jetzt entscheidend ist, ist die Zeit, die benötigt wird, um eine Funktion von der internen Genehmigung bis zum Bildschirm eines Abonnenten zu bringen, auf allen Plattformen, die Sie bedienen. Nennen Sie es Feature Velocity. Fast niemand misst es, bis die Woche kommt, in der dringend etwas benötigt wird und sich herausstellt, dass es nicht verfügbar ist.

So messen Sie Feature Velocity auf einer Streaming-Plattform

2 Fragen, und Sie können beide noch heute Nachmittag stellen.

Wie oft deployt Ihre Plattform? Der 2025 DORA-Bericht, basierend auf Antworten von fast 5.000 Technologiefachleuten, stellte fest, dass etwa 23 % der Teams jetzt mindestens einmal täglich deployen. Wenn Ihre ehrliche Antwort lautet „immer wenn der Anbieter ein Update pusht“, erhalten Sie Änderungen monatlich oder vierteljährlich. Dieses Tempo wird durch die darunter liegende Architektur bestimmt.

Was ist Ihre Lead Time? Von der internen Genehmigung bis zu einem Abonnenten, der die Funktion nutzt – wie viele Wochen dauert das? Wenn der Weg über das Scoping, die Planung, das QA und den Release-Kalender eines anderen Unternehmens führt, zählen Sie in Monaten. Wenn Sie die Pipeline besitzen, ist eine am Montag genehmigte Änderung am Mittwoch in der Sprint-Planung und innerhalb von zwei Wochen im Test.

Wer kontrolliert Ihren OTT-Plattform-Release-Zeitplan?

Auf einer White-label-Plattform nicht Sie – und Freitagabend merken Sie es.

Store-Einreichungen und Gerätezertifizierungen laufen nach dem Zeitplan des Anbieters, was in Ordnung ist, bis Abonnenten während eines Live-Spiels auf Abstürze stoßen. Sie können den Fix nicht selbst einspielen. Sie eröffnen ein Ticket. Und während Sie auf das Release-Fenster von jemandem anderem warten, tut das auch Ihr Publikum – in Echtzeit, in der einen Nacht der Woche, die Sie sich nicht leisten können.

„Sie eröffnen ein Ticket. Und während Sie auf das Release-Fenster von jemandem anderem warten, tut das auch Ihr Publikum.“

Warum vergrößert jedes Gerät, das Sie hinzufügen, den Unterschied?

Weil bei separaten Codebases jedes Feature so oft veröffentlicht wird, wie Sie Plattformen haben.

Ein typischer Broadcaster bedient iOS, Android, Web, Fire TV, Roku, Samsung Tizen und LG webOS, oft auch Apple TV und Android TV. 7 bis 10 Ziele. Wenn diese separat gepflegt werden, kommt eine Funktion eine Plattform nach der anderen: zuerst iOS, dann Android, Connected TV wann immer Kapazität vorhanden ist. Bei einer modularen Architektur mit einer gemeinsamen Komponentenschicht wird die Änderung einmal veröffentlicht und landet überall. Jedes Gerät, das Sie hinzufügen, macht diesen Unterschied größer.

Was ist die Velocity Inversion in der OTT-Plattform-Entwicklung?

Es ist der Moment, in dem der Broadcaster, der am schnellsten gestartet ist, zum langsamsten bei der Veröffentlichung wird.

Das ist der Teil, der Technikdirektoren unvorbereitet trifft. White-label bringt Sie in Wochen live. 18 Monate später führt jede gewünschte Änderung durch den Backlog des Anbieters und kommt nach dem Release-Zeitplan des Anbieters an, sodass Sie sich unbegrenzt in seinem Tempo bewegen. Währenddessen hat das Team, das seine eigene Plattform gebaut hat, 12 bis 18 Monate damit verbracht, in die Produktion zu gehen – und begann dann, seine eigene Uhr zu kontrollieren.

Anfangs ist der Tausch offensichtlich lohnenswert. Sie sind live und Ihr Mitbewerber befindet sich noch in der Entwicklung. Ein Jahr später ist Ihr Mitbewerber ebenfalls live, veröffentlicht wöchentlich, und Sie warten auf Q3. Fora Soft kam zu einem ähnlichen Schluss in ihrem Build-vs-Buy-Leitfaden für 2026: Für hybride Monetarisierung über SVOD, AVOD und FAST amortisiert sich ein Custom Build innerhalb von 18 bis 24 Monaten.

Wann ist White-label immer noch die richtige Antwort?

Wenn der Katalog unkompliziert ist und das Produkt sich nicht differenzieren muss.

Ich sage das lieber offen, als so zu tun, als wäre die Alternative kostenlos. Ein Custom Build braucht 12 bis 18 Monate, um in die Produktion zu gehen, und für eine Reihe von Broadcastern bleibt White-label die zahlenmäßig richtige Entscheidung.

Aber wenn Sie um dieselben Abonnenten konkurrieren wie Netflix, das kontinuierlich deployt, oder DAZN, das 2026 mehr als 3 Milliarden Dollar für Live-Rechte ausgibt und sein eigenes Frontend betreibt, verschärft sich die Frage erheblich. Können Sie es sich leisten, Ihrem Markt nächstes Jahr statt diese Saison zu antworten?

Bewerten Sie Ihre Feature-Velocity-Position

3 Fragen. Beantworten Sie jede mit Ja oder Nein.

Kennen Sie die aktuelle Deployment-Frequenz Ihrer Plattform – nicht den Release-Zyklus des Anbieters, sondern wie oft Code tatsächlich die Abonnenten erreicht?

Wenn Sie heute ein Feature genehmigen würden, könnten Sie die Kalenderwoche nennen, in der es jede Plattform, die Sie bedienen, erreichen würde?

Wenn an einem Freitagabend während eines Live-Spiels ein Absturz auftritt, kann Ihr Team einen Fix einspielen, ohne ein Ticket zu eröffnen?

Wir bauen diese Systeme. Wenn Sie besprechen möchten, wie eine hochperformante OTT-Architektur für Ihre Plattform aussieht, nehmen Sie Kontakt auf.

Die eine Zahl, die Sie anfangen sollten zu verfolgen

Feature Velocity läuft auf eine einzige Frage der Eigenverantwortung hinaus: Wenn Sie die Pipeline kontrollieren, veröffentlichen Sie, wenn der Markt es braucht. Wenn nicht, veröffentlichen Sie, wenn der Anbieter Sie erreicht.

Der Broadcaster mit den 2 Kommentarsprachen misst es jetzt. Er sah, wie sich ein Sechs-Wochen-Fenster gegen ein Acht-Wochen-Angebot schloss, und wollte diese Zahl nie wieder hören.

Wenn Ihre ehrliche Antwort auf „Wie lange würde das dauern?“ lautet „Ich frage den Anbieter“, gehört der Zeitplan bereits jemand anderem. Das ist ein Gespräch, das es wert ist, auf der IBC in diesem Jahr zu führen, Stand 5.F51.

Häufig gestellte Fragen

Wie berechne ich Feature Velocity für meine Streaming-Plattform?

Verfolgen Sie zwei Zahlen: Deployment-Frequenz (wie oft Code die Abonnenten erreicht) und Lead Time (Kalendertage von der internen Genehmigung bis zum Go-live eines Features auf allen Plattformen). Der 2025 DORA-Bericht setzt Elite-Teams mit mehreren Deployments pro Tag als Benchmark. Wenn Ihre Antwort davon abhängt, wann der Anbieter als nächstes einen Release plant, messen Sie dessen Velocity, nicht Ihre eigene.

Kann ich die Feature Velocity auf einer White-label-OTT-Plattform verbessern?

In gewissem Maß. Sie können Ihren eigenen Genehmigungsprozess straffen und das Hin und Her bei Spezifikationen reduzieren. Aber die Release-Pipeline, Store-Einreichungen, Gerätezertifizierungen und der QA-Zyklus gehören dem Anbieter. Das sind strukturelle Einschränkungen, keine Prozessprobleme. Die Obergrenze ist seine Architektur, und keine interne Effizienz ändert daran etwas.

Wann wird eine maßgeschneidert entwickelte OTT-Plattform schneller als White-label?

Typischerweise 12 bis 18 Monate nach dem Produktionslaunch. Davor ist White-label per Definition schneller auf dem Markt. Danach kontrolliert der Custom Build seinen eigenen Release-Zyklus und beginnt, den Vorteil mit jedem Sprint zu vergrößern. Fora Softs Analyse für 2026 setzt den finanziellen Break-even bei 18 bis 24 Monaten für hybride Monetarisierungsmodelle an.