Kernbevindingen in 60 seconden
- De maatstaf die er na de lancering toe doet, is feature velocity: hoe lang een functionaliteit erover doet om van interne goedkeuring naar het scherm van een abonnee te gaan.
- Twee vragen meten het — deployfrequentie en doorlooptijd. Je kunt ze allebei vanmiddag stellen.
- Op een white-label-platform behoort jouw releaseplanning toe aan de leverancier. Op een maatwerk-build behoort die aan jou.
- Elk apparaat dat je toevoegt vergroot het verschil tussen architecturen met gedeelde componenten en afzonderlijke codebases.
- De omroep die het snelst lanceerde, wordt vaak degene die het traagst levert — de velocity inversion.
6 weken op de kalender. 8 weken in de offerte.
Dat was het hele probleem, en het paste in twee cijfers. Een omroep waarmee ik samenwerk, wilde kijkers de keuze geven tussen twee commentaartalen op dezelfde livestream — het soort aanpassing dat op een modern platform een configuratiebeslissing is, meetbaar in dagen. Hun white-label-leverancier kwamen terug met 8 weken. Het rechtenvenster voor die uitzending opende na zes.
De wedstrijd ging dus in één taal de lucht in. Het publiek waarvoor het was opgebouwd keek op de app van een concurrent, en tegen de tijd dat de functionaliteit technisch beschikbaar was, was de wedstrijd die hem rechtvaardigde al gespeeld.
Niemand in dat verhaal deed iets onzorgvuldigs. Het verzoek was redelijk, de schatting van de leverancier was waarschijnlijk eerlijk, en de technisch directeur had het goedgekeurd zodra het op zijn bureau belandde. Hij ontdekte gewoon — op het slechtst mogelijke moment — dat de klok nooit van hem was geweest.
“Iemand binnen de omroep zegt ja, en ontdekt vervolgens hoe lang ja eigenlijk duurt als de tijdlijn aan iemand anders toebehoort.”
Ik heb dat patroon tientallen keren zien herhalen in projecten. De details zijn nooit hetzelfde. Offline downloads op één apparaattype. Een weddenschapintegratie die een rechtenvenster achtervolgt. Een betaalmethode waar niemand aan had gedacht totdat de app live was in een nieuwe markt. Maar het moment is elke keer identiek: iemand binnen de omroep zegt ja, en ontdekt vervolgens hoe lang ja eigenlijk duurt als de tijdlijn aan iemand anders toebehoort.
Waarom lanceersnelheid de verkeerde maatstaf is voor jouw OTT-platform
Omdat je al gelanceerd bent.
De sector praat nog steeds over “time to market” alsof dat lanceersnelheid betekent — hoe snel een app 5 winkels bereikt op elk apparaat. Op die maatstaf wint white-label ronduit, en het bewijs is moeilijk te weerleggen: 6 tot 12 weken van contract tot live, inclusief merkmaatwerk.
Maar de meeste Europese streamingoperators zijn 2 tot 4 jaar geleden live gegaan. Die race is voorbij en niemand houdt er nog score van bij. Het getal dat nu de doorslag geeft, is hoe lang het duurt om een functionaliteit van interne goedkeuring naar het scherm van een abonnee te brengen, op elk platform dat je bedient. Noem het feature velocity. Bijna niemand meet het — totdat ze in de week dat ze iets dringend nodig hebben erachter komen dat ze het niet kunnen krijgen.
Hoe meet je feature velocity op een streamingplatform
2 vragen, en je kunt ze allebei vanmiddag stellen.
Hoe vaak deployt jouw platform? Het 2025 DORA-rapport, gebaseerd op antwoorden van bijna 5.000 technologieprofessionals, stelde vast dat ongeveer 23% van de teams nu minstens één keer per dag deployt. Als je eerlijke antwoord is “wanneer de leverancier een update pusht,” ontvang je wijzigingen maandelijks of per kwartaal. Dat tempo wordt bepaald door de architectuur onder je.
Wat is je doorlooptijd? Van interne goedkeuring tot een abonnee die er gebruik van maakt, hoeveel weken zijn dat? Als het pad loopt via de scope, planning, QA en releaseplanning van een ander bedrijf, tel je in maanden. Wanneer jij de pipeline bezit, staat een op maandag goedgekeurde wijziging woensdag in de sprintplanning en binnen twee weken in testing.
Wie bepaalt jouw OTT-platform releaseplanning?
Op een white-label-platform ben jij het niet — en vrijdagavond merk je dat.
Indieningen bij stores en apparaatcertificering verlopen op het schema van de leverancier, wat prima is totdat abonnees tijdens een live wedstrijd crashes beginnen te ervaren. Je kunt de fix niet zelf pushen. Je dient een ticket in. En terwijl jij wacht tot het releasevenster van iemand anders opengaat, doet je publiek dat ook — in real time, op de ene avond van de week die je je niet kunt veroorloven.
“Je dient een ticket in. En terwijl jij wacht tot het releasevenster van iemand anders opengaat, doet je publiek dat ook.”
Waarom vergroot elk apparaat dat je toevoegt het verschil?
Omdat bij afzonderlijke codebases elke functie net zo vaak wordt uitgebracht als je platforms hebt.
Een typische omroep bedient iOS, Android, web, Fire TV, Roku, Samsung Tizen en LG webOS, vaak ook Apple TV en Android TV. 7 tot 10 doelplatforms. Als die afzonderlijk worden onderhouden, komt een functionaliteit één platform tegelijk: eerst iOS, dan Android, connected TV wanneer er capaciteit is. Op een modulaire architectuur met een gedeelde componentenlaag wordt de wijziging eenmaal uitgebracht en landt overal. Elk apparaat dat je toevoegt maakt dat verschil groter.
Wat is de velocity inversion bij OTT-platformontwikkeling?
Het is het moment waarop de omroep die het snelst lanceerde, degene wordt die het traagst levert.
Dit is het deel dat technisch directeuren verrast. White-label zet je binnen weken live. 18 maanden later loopt elke gewenste wijziging via de backlog van de leverancier en komt aan op zijn releaseplanning, zodat je voor onbepaalde tijd op hun tempo beweegt. Ondertussen heeft het team dat zijn eigen platform heeft gebouwd 12 tot 18 maanden besteed aan het bereiken van productie — en begon daarna zijn eigen klok te besturen.
In het begin is de afweging duidelijk de moeite waard. Je bent live en je concurrent is nog in ontwikkeling. Een jaar later is je concurrent ook live, levert wekelijks, en wacht jij op Q3. Fora Soft bereikte een vergelijkbare conclusie in hun build-vs-buy-draaiboek van 2026: voor hybride monetisatie via SVOD, AVOD en FAST verdient een maatwerkontwikkeling zichzelf terug binnen 18 tot 24 maanden.
Wanneer is white-label nog steeds het juiste antwoord?
Wanneer de catalogus eenvoudig is en het product niet hoeft te differentiëren.
Ik zeg dat liever ronduit dan te doen alsof het alternatief gratis is. Een maatwerkontwikkeling duurt 12 tot 18 maanden om productie te bereiken, en voor een aantal omroepen blijft white-label de juiste beslissing op basis van de cijfers.
Maar als je concurreert voor dezelfde abonnees als Netflix, dat continu deployt, of DAZN, dat in 2026 meer dan $3 miljard uitgeeft aan live-rechten en zijn eigen front-end draait, wordt de vraag aanzienlijk scherper. Kun je het je veroorloven om pas volgend jaar op je markt te reageren in plaats van dit seizoen?
Meet je feature velocity positie
Het ene getal om bij te gaan houden
Feature velocity draait uiteindelijk neer op één eigendomsvraag: als jij de pipeline beheert, lever je wanneer de markt het nodig heeft. Als je dat niet doet, lever je wanneer de leverancier bij je uitkomt.
De omroep met de 2 commentaartalen meet het nu. Hij zag een venster van zes weken sluiten tegen een offerte van acht weken en wilde dat getal nooit meer te horen krijgen.
Als je eerlijke antwoord op “hoe lang zou dit duren?” is “laat me de leverancier vragen,” behoort de tijdlijn al aan iemand anders toe. Dat is een gesprek dat de moeite waard is om te voeren op IBC dit jaar, Stand 5.F51.
Veelgestelde vragen
Hoe bereken ik feature velocity voor mijn streamingplatform?
Volg twee getallen: deployfrequentie (hoe vaak code bij abonnees terechtkomt) en doorlooptijd (kalenderdagen van interne goedkeuring tot een functie live is op alle platforms). Het 2025 DORA-rapport benchmarkt elite-teams op meerdere deploys per dag. Als je antwoord afhangt van wanneer de leverancier de volgende release inplant, meet je hun velocity, niet die van jou.
Kan ik feature velocity verbeteren op een white-label OTT-platform?
Tot op zekere hoogte. Je kunt je eigen goedkeuringsproces stroomlijnen en het heen-en-weer over specificaties verminderen. Maar de release-pipeline, store-indieningen, apparaatcertificering en QA-cyclus behoren toe aan de leverancier. Dat zijn structurele beperkingen, geen procesproblemen. Het plafond is hun architectuur, en geen enkele interne efficiëntie verandert dat.
Wanneer wordt een custom OTT-platform sneller dan white-label?
Doorgaans 12 tot 18 maanden na de productielancering. Daarvoor is white-label per definitie sneller op de markt. Daarna beheert de custom build zijn eigen releasecyclus en begint het voordeel met elke sprint te vergroten. De 2026-analyse van Fora Soft plaatst het financiële break-evenpunt op 18 tot 24 maanden voor hybride monetisatiemodellen.
