Kosten OTT-app-ontwikkeling: uitsplitsing per platform 2026

Kernbevindingen in 60 seconden

1. Een OTT-product is geen app. Het is een portfolio van apps voor mobiel, web, smart-tv en set-top boxes, elk met een eigen taal, certificeringstraject en kostenprofiel.
2. Het verschil tussen het goedkoopste platform (web) en het meest beperkte (Roku) kan drie op één zijn, puur op arbeidskosten, nog voordat je de certificeringstermijnen meerekent.
3. Cross-platform tooling is verbeterd, maar elk framework-traject hangt af van een leverancier die blijft kiezen voor ondersteuning. Amazon liet net zien hoe snel die aanname kan vervallen.
4. Native verdient zijn geld in de medialaag. Bij live sport is de laatste 10% aan native-gelijkwaardig gedrag precies de 10% die ertoe doet.
5. Begin met een lijst van de platforms die je publiek daadwerkelijk gebruikt, en prijs ze vervolgens los van elkaar.

Het bestuur keurde een budget goed voor “de app.” Enkelvoud.

Een paar weken later zat ik in de kamer toen de technisch directeur doornam wat “de app” eigenlijk betekende: iOS, Android, web, Samsung, LG, Fire TV, Roku, en een Apple TV-build die iemand van commercie al aan een sponsor had beloofd. Acht platforms. Vier verschillende programmeertalen. Drie afzonderlijke certificeringsprocessen met drie afzonderlijke wachtrijen.

Niemand had tegen het bestuur gelogen. De vraag was gewoon enkelvoudig gesteld, en er kwam een enkelvoudig antwoord terug: één getal, voor één app, alsof een streamingproduct één ding is in plaats van een verzameling dingen. De werkelijke kosten van OTT-app-ontwikkeling waren acht getallen, en niemand had erom gevraagd ze los van elkaar te zien. Het budget klopte niet, met een veelvoud.

Het budget klopte niet, met een veelvoud.

Drie vragen doen er meer toe dan het totaal: wat elk platform kost, welke je dit jaar daadwerkelijk nodig hebt, en wie de controle heeft over de laag waar live video het ofwel doet, ofwel je te schande maakt.

De kostenopbouw van het OTT-platform die besturen over het hoofd zien

De meeste organisaties beginnen met één getal voor “de front-end.” Dat getal klopt vrijwel nooit (niet met 20% afwijking, maar met een factor drie of vier) omdat niemand de vraag heeft opgesplitst naar platforms.

Een OTT-product is geen app. Het is een portfolio van apps voor mobiel, web, smart-tv en set-top boxes, elk met een eigen taal, een eigen certificeringstraject en een eigen kostenprofiel. Het verschil in OTT-platformontwikkelingskosten tussen het goedkoopste platform (web) en het meest beperkte (Roku) kan drie op één zijn, puur op arbeidskosten, nog voordat je de certificeringstermijnen meerekent.

Inzicht in de kosten van OTT-app-ontwikkeling begint met één vraag: voor welke platforms bouw je? Dit is wat de kosten per platform daadwerkelijk bepaalt:

Twee getallen doen er meer toe dan de build zelf. Onderhoud kost jaarlijks 15–20% van de bouwkosten. En de initiële build is doorgaans slechts zo’n 30% van je uitgaven in het eerste jaar, zodra infrastructuur, DRM en datatransfer zijn meegeteld. De front-end is het zichtbare deel van de rekening, niet de hele rekening.

Begin met een lijst van de platforms die je publiek daadwerkelijk gebruikt, en prijs ze vervolgens los van elkaar.

Waarom dezelfde app op het ene platform drie keer zoveel kost als op het andere

Omdat het platform je taal bepaalt, en twee daarvan doen dat slecht.

Zes televisiebesturingssystemen, maar slechts drie programmeermodellen. Samsung, LG en Hisense draaien HTML5-webapps. Android TV en het oudere Fire OS draaien Kotlin tegen ExoPlayer. Roku draait BrightScript, een eigen taal die Roku in de jaren 2000 heeft bedacht, op een scene-graph UI-framework dat geen enkel ander platform gebruikt. Zo gegroepeerd hebben zes platforms drie of vier player-implementaties nodig in plaats van zes, en dat is het meest bruikbare kosteninzicht voor iedereen die dit budget plant.

Bij Roku gaan ramingen het vaakst mis (we schreven eerder apart over beter bouwen voor tv-apps op Roku, maar het kostenverhaal begint hier). Er is geen Kotlin-traject, geen JavaScript-traject, geen ontsnappingsroute via een framework: BrightScript of niets. Certificering duurt vier tot acht weken en test tegen hardware waaronder de instapmodel Express, die op een sub-1GHz single-core met 256MB RAM draait. Een UI die vloeiend draait op een Roku Ultra en frames laat vallen op een Express wordt afgewezen. Dat is geen moeilijke app. Het is een anders moeilijke app, en daar heb je mensen voor nodig die er al eerder een hebben uitgebracht.

Er is geen Kotlin-traject, geen JavaScript-traject, geen ontsnappingsroute via een framework: BrightScript of niets.

Kunnen we het niet gewoon één keer bouwen en overal uitrollen?

Deels. In oktober 2025 liet Amazon precies zien wat die gok kost als het misgaat.

Fire TV was ooit een fork van Android, dus een Fire TV-app was een Android-app met een andere winkelvermelding. Toen begon Amazon Fire OS te vervangen door Vega OS, een op Linux gebaseerd systeem gebouwd op React Native en webtechnologie. Een Android-APK draait er niet op. Tegen januari 2026 had Amazon bevestigd dat alle toekomstige Fire TV Sticks met Vega worden uitgeleverd, wat betekent dat elke omroep die aanwezig wil zijn op nieuwe Amazon-hardware nu een volledig nieuwe app moet bouwen.

Let op de ironie, want die is leerzaam: het “cross-platform” framework is nu de verplichte native stack op één platform. We signaleerden deze verschuiving (samen met FAST-kanalen en de economie van advertentietiers) in onze OTT-trends voor 2026. Dit is het kernargument tegen het inzetten van een strategie op één enkele abstractielaag. Cross-platform tooling is verbeterd. React Native-teams melden 60–80% codehergebruik over tv-doelen heen, Samsung ondersteunt Flutter via flutter-tizen, LG bouwt al enige tijd aan een webOS Flutter SDK. Maar elk van die trajecten hangt af van een leverancier die blijft kiezen voor ondersteuning, en Amazon liet net zien hoe snel die aanname kan vervallen.

Als het platform verandert, betekent een native codebase dat je één platform herschrijft. Een framework-afhankelijkheid betekent dat je wacht tot iemand anders bijbenen, en jij bepaalt niet wanneer dat gebeurt, of of het überhaupt gebeurt.

Waar native zijn geld verdient

In de medialaag. Bij live sport is dat het hele product.

Bladerschermen en rasters zijn niet waar abstractie pijn doet. Afspelen wel. Elke harde eis bij live sport zit binnen één of twee API-aanroepen van de eigen player van het platform: low-latency live-rand, hardwaregebonden DRM voor premium rechten, meerdere audiotracks voor commentaartalen, trick play tegen een doorlopend DVR-venster, en adaptieve bitrate die standhoudt wanneer 400.000 mensen binnen dezelfde negentig seconden aanhaken.

Native geeft je AVPlayer, ExoPlayer en AVPlay rechtstreeks: dezelfde stack die we gebruiken bij het bouwen van sportstreamingervaringen. Een cross-platform laag geeft je een wrapper eromheen, en wrappers lopen een release-cyclus of twee achter op het platform. Dat gat is onzichtbaar bij een catalogus vol dramaboxsets en genadeloos bij de aftrap. De vuistregel uit de engineering (de laatste 10% van native-gelijkwaardig gedrag kost het meest) beschrijft toevallig precies de 10% waarvan live sport afhankelijk is.

De laatste 10% van native-gelijkwaardig gedrag kost het meest, en die beschrijft toevallig precies de 10% waarvan live sport afhankelijk is.

Welk streamingplatform bouw je als eerste?

Begin waar je kijktijd al zit. Voeg daarna het platform toe dat je commerciële team heeft beloofd. In die volgorde.

De regionale verdeling doet er meer toe dan elke algemene aanbeveling. In de VS heeft Roku ongeveer 28% van de televisies in gebruik en Samsungs Tizen zo’n 23%. Wereldwijd voeren Android TV en Google TV de boventoon met 35–40%, met Tizen rond 19–23% en Roku rond 10%. Europa neigt naar Samsung en LG in de woonkamer, met Android TV van belang op set-top boxes van operators.

De juiste volgorde hangt af van je publiek, je contentmodel en waar je commerciële toezeggingen al liggen. We hebben omroepen, sportfederaties en D2C-platforms geholpen dit uit te zoeken, en het antwoord verschilt elke keer. Maar wat ik niet zou doen, is in jaar één alle acht platforms aanschaffen. Breng er drie fatsoenlijk uit, meet ze, en laat echt gebruik je vertellen wat de vierde moet worden. Welke drie je ook kiest, hoe snel je de volgende functie over al die platforms kunt uitrollen doet er bijna net zoveel toe als welke drie je koos.

Score je platformbudgetpositie

Wat kost OTT-app-onderhoud in jaar twee?

Ongeveer 15–20% van de build per jaar, plus de lange staart aan certificering en firmware die niemand in de business case opneemt.

Elk modeljaar voegt firmwarevarianten toe. Samsungs Tizen gedraagt zich anders per line-up; oudere LG webOS-toestellen implementeren een HLS-revisie uit 2014, wat betekent dat je een JavaScript-player moet uitleveren in plaats van te vertrouwen op native afspelen. Roku hercertificeert. Apple en Google veranderen winkelvereisten. Een testmatrix die alleen dit jaars vlaggenschiptelevisies dekt, test niet je publiek. Het test het hoekje ervan dat onlangs een tv heeft gekocht.

Deze lange staart is waar veel organisaties ontdekken dat ze een ontwikkelpartner nodig hebben, niet alleen een leverancier die bouwt en overdraagt. De front-end is een product en heeft dezelfde doorlopende zorg nodig als de content die het levert. De monetisatiestrategie goed krijgen is net zo belangrijk: SVOD, AVOD of hybride, elk model verandert wat de front-end moet ondersteunen.

Wanneer is cross-platform de juiste keuze?

Wanneer je catalogus bestaat uit langlopende VOD, je onderscheidend vermogen in content zit in plaats van in het product, en snelheid naar de markt zwaarder weegt dan afspeelprestaties.

Dat zeg ik liever ronduit dan te doen alsof native universeel de juiste keuze is. Als je een eenvoudige on-demand bibliotheek uitrolt naar acht platforms met een beperkt budget, is een framework met 60–80% hergebruik een rationele afweging. Hergebruik van de webstack over Samsung, LG en Hisense is efficiënt: die drie delen hetzelfde programmeermodel, of je nu een framework gebruikt of niet.

Maar als je live-rechten hebt, als latency, DRM en meerdere audiotracks contractueel verplicht zijn in plaats van een leuke bijkomstigheid, en als het product bedoeld is om te onderscheiden in plaats van louter te leveren, ga je hoe dan ook native code schrijven in de afspeellaag. Beter daar rekening mee te houden dan het te ontdekken in een stadion op een zaterdag.

Het getal dat je aan je bestuur voorlegt

De werkelijke kosten van OTT-app-ontwikkeling zijn de kosten per platform, vermenigvuldigd met de platforms die je over drie jaar nog steeds zelf beheert.

De omroep uit de opening kreeg uiteindelijk een realistisch cijfer goedgekeurd. Wat het gesprek veranderde, was één woord vervangen door een lijst, en vragen welke items op die lijst hun publiek dit seizoen daadwerkelijk zou opmerken.

Als je nu die lijst aan het opstellen bent, of aankijkt tegen een budget dat enkelvoudig is goedgekeurd, dan moeten we praten. Je kunt ook verkennen hoe een white-label OTT-platform de build-versus-buy-rekensom verandert voor een deel van die platforms, en als een white-label-leverancier al een deel van je stack in handen heeft, hier lees je hoe je nagaat of je roadmap nog van jou is. We zijn ook aanwezig op IBC Amsterdam deze september, stand 5.F51, en dit is precies het gesprek dat we voeren met elke omroep en federatie die langskomt.

Veelgestelde vragen

Hoeveel kost het om een OTT-app voor één platform te bouwen?

De kosten van OTT-app-ontwikkeling voor één platform hangen af van voor welk platform je bouwt. Een webplayer is het goedkoopste platform; een Roku-app gebouwd in BrightScript tegen low-end hardware met een certificeringscyclus van 4–8 weken is het duurst. Het verschil kan drie op één zijn, puur op ontwikkelarbeid, nog voordat je DRM-licenties, infrastructuur en certificeringskosten meerekent. Als je je afvraagt hoeveel het kost om een OTT-platform te bouwen, is het antwoord: vraag in plaats daarvan hoeveel elk platform kost, en welke drie je als eerste nodig hebt.

Waarom is bouwen voor Roku zoveel duurder dan voor andere tv-platforms?

BrightScript. Het is een eigen taal die alleen op Roku draait, op een scene-graph UI-framework dat geen enkel ander platform gebruikt. Er is geen JavaScript-traject, geen Kotlin-traject, geen ontsnappingsroute via cross-platform. Certificering test tegen hardware waaronder de instapmodel Express met een sub-1GHz processor en 256MB RAM, dus prestatie-optimalisatie is verplicht. De combinatie van een unieke taal, beperkte hardware en een certificeringswachtrij van 4–8 weken maakt Roku het duurste connected-tv-platform om voor te bouwen en te onderhouden.

Moet ik een native OTT-app bouwen of een cross-platform framework gebruiken?

Dat hangt af van je contentmodel. Als je langlopende VOD uitlevert en snelheid naar de markt het belangrijkst is, is een cross-platform framework met 60–80% codehergebruik een rationele afweging. Als je live sportrechten hebt, waarbij low-latency afspelen, hardware-DRM, meerdere audiotracks en adaptieve bitrate onder gelijktijdige piekbelasting contractuele vereisten zijn, ga je hoe dan ook native code schrijven in de afspeellaag. De vraag is of je daar rekening mee houdt of het ontdekt op wedstrijddag.

Wat is er gebeurd met Amazon Fire TV en Vega OS?

Amazon begon Fire OS (een Android-fork) te vervangen door Vega OS, een op Linux gebaseerd systeem gebouwd op React Native en webtechnologie. Een Android-APK draait niet op Vega. Tegen januari 2026 bevestigde Amazon dat alle toekomstige Fire TV Sticks met Vega worden uitgeleverd, wat betekent dat elke omroep die aanwezig wil zijn op nieuwe Amazon-hardware nu een volledig nieuwe app moet bouwen, zelfs als ze al een Fire TV-app hadden draaien op het oude, op Android gebaseerde systeem.

Op hoeveel OTT-platforms moet ik in het eerste jaar lanceren?

Drie, degelijk gebouwd en van meetinstrumentatie voorzien. Lanceer waar je kijktijd al zit, voeg het platform toe dat je commerciële team heeft beloofd, en laat echte gebruiksdata je vertellen wat het vierde moet worden. Alle acht platforms in jaar één aanschaffen spreidt budget en QA te dun uit en betekent meestal dat geen van alle goed genoeg werkt om abonnees door het eerste seizoen heen vast te houden.

Hoeveel kost een streaming-app?

De ontwikkelkosten van een streaming-app hangen af van wat je bedoelt met "een app." Bedoel je één enkele webgebaseerde player, dan is dat het goedkoopste platform om te bouwen. Bedoel je een volledig multiplatform streamingproduct (iOS, Android, web, smart-tv's, set-top boxes), dan is het totaal doorgaans drie tot vijf keer zo hoog als waar de meeste teams voor één platform op budgetteren. Infrastructuur, DRM-licenties, contentdistributie en doorlopend onderhoud brengen bovenop de front-end-build extra kosten met zich mee. Het nuttigste startpunt is een lijst maken van de platforms die je publiek daadwerkelijk gebruikt en die los van elkaar te prijzen.

Wat kost smart-tv-app-ontwikkeling in vergelijking met mobiel?

Smart-tv-app-ontwikkeling (Samsung Tizen, LG webOS, Android TV, Roku) kost doorgaans meer per platform dan mobiel (iOS of Android). De redenen zijn fragmentatie per modeljaar, eigen SDK's (BrightScript op Roku, AVPlay op Samsung), en certificeringstermijnen die per release vier tot acht weken kunnen toevoegen. Een gedeeld designsysteem voor iOS en Android drukt de kosten van de tweede mobiele build omlaag, maar elk tv-platform is in feite een aparte build met een eigen taal, testmatrix en indieningsproces.