Punti chiave in 60 secondi
- La metrica che conta dopo il lancio è la velocità delle funzionalità: quanto tempo impiega una funzionalità per passare dall'approvazione interna allo schermo di un abbonato.
- Due domande la misurano — frequenza di deploy e lead time. Puoi porle entrambe questo pomeriggio.
- Su una piattaforma white-label, il calendario di rilascio appartiene al fornitore. Su un build personalizzato, appartiene a te.
- Ogni dispositivo che aggiungi amplia il divario tra architetture a componenti condivisi e codebase separate.
- Il broadcaster che ha lanciato più velocemente diventa spesso quello che rilascia più lentamente — l'inversione della velocità.
6 settimane sul calendario. 8 settimane nel preventivo.
Questo era l’intero problema, e stava tutto in due numeri. Un broadcaster con cui collaboro aveva bisogno di permettere agli spettatori di scegliere tra due lingue del commento sullo stesso live stream, il tipo di modifica che su uno stack moderno è una decisione di configurazione, misurabile in giorni. Il loro fornitore white-label rispose con 8 settimane. La finestra dei diritti per quella trasmissione si apriva in sei.
Così la partita andò in onda in una sola lingua. Il pubblico per cui era stata costruita la seguì sull’app di un competitor, e quando la funzionalità fu tecnicamente disponibile, la gara che l’aveva giustificata era già stata disputata.
Nessuno in quella storia ha agito con superficialità. La richiesta era ragionevole, la stima del fornitore era probabilmente onesta, e il direttore tecnico l’aveva approvata nel momento in cui era arrivata sulla sua scrivania. Semplicemente scoprì — nel peggior momento possibile — che il tempo non era mai stato suo.
“Qualcuno all’interno del broadcaster dice sì, e poi scopre quanto tempo impiega quel sì quando la tempistica appartiene a qualcun altro.”
Ho visto ripetersi quella stessa dinamica in decine di progetti. I dettagli non sono mai identici. Download offline su un tipo di dispositivo. Un’integrazione con le scommesse in corsa contro una finestra di diritti. Un metodo di pagamento a cui nessuno aveva pensato finché l’app non era già live in un nuovo mercato. Ma il momento è sempre identico: qualcuno all’interno del broadcaster dice sì, e poi scopre quanto tempo impiega quel sì quando la tempistica appartiene a qualcun altro.
Perché la velocità di lancio è la metrica sbagliata per la tua piattaforma OTT
Perché sei già in produzione.
Il settore parla ancora di “time to market” come se significasse velocità di lancio — quanto velocemente un’app raggiunge 5 store su ogni dispositivo. Con questa misura il white-label vince in modo netto, e le prove sono difficili da contestare: da 6 a 12 settimane dal contratto al live, personalizzazione del brand inclusa.
Ma la maggior parte degli operatori streaming europei è andata live 2 o 4 anni fa. Quella gara è finita, e nessuno la sta più tenendo il punteggio. Il numero che conta ora è quanto tempo ci vuole per portare una funzionalità dall’approvazione interna allo schermo di un abbonato, su ogni piattaforma che servi. Chiamala velocità delle funzionalità. Quasi nessuno la misura finché nella settimana in cui ha urgentemente bisogno di qualcosa non scopre di non poterla avere.
Come misurare la velocità delle funzionalità su una piattaforma streaming
2 domande, e puoi farle entrambe questo pomeriggio.
Con quale frequenza la tua piattaforma effettua deploy? Il report DORA 2025, basato sulle risposte di quasi 5.000 professionisti tecnologici, ha rilevato che circa il 23% dei team ora esegue il deploy almeno una volta al giorno. Se la tua risposta onesta è “ogni volta che il fornitore pubblica un aggiornamento”, stai ricevendo modifiche mensilmente o trimestralmente. Quel ritmo è determinato dall’architettura sottostante.
Qual è il tuo lead time? Dall’approvazione interna a quando un abbonato usa la funzionalità, quante settimane? Se il percorso passa attraverso la fase di scoping, pianificazione, QA e calendario di rilascio di un’altra azienda, stai contando in mesi. Quando possiedi la pipeline, una modifica approvata il lunedì è nel planning dello sprint entro il mercoledì e in fase di test entro due settimane.
Chi controlla il calendario di rilascio della tua piattaforma OTT?
Su una piattaforma white-label, non tu — e il venerdì sera è quando te ne accorgi.
Le submission agli store e le certificazioni dei dispositivi seguono il calendario del fornitore, il che va bene finché gli abbonati non iniziano a segnalare crash durante una partita in diretta. Non puoi pubblicare tu stesso la correzione. Apri un ticket. E mentre aspetti che si apra la finestra di rilascio di qualcun altro, lo stesso fa il tuo pubblico, in tempo reale, nella sera della settimana in cui non puoi permettertelo.
“Apri un ticket. E mentre aspetti che si apra la finestra di rilascio di qualcun altro, lo stesso fa il tuo pubblico.”
Perché ogni dispositivo che aggiungi amplia il divario?
Perché su codebase separate, ogni funzionalità viene rilasciata tante volte quante sono le piattaforme che gestisci.
Un broadcaster tipico serve iOS, Android, web, Fire TV, Roku, Samsung Tizen e LG webOS, spesso anche Apple TV e Android TV. Da 7 a 10 target. Se questi vengono mantenuti separatamente, una funzionalità arriva una piattaforma alla volta: prima iOS, poi Android, poi la connected TV quando c’è capacità. Su un’architettura modulare con un layer di componenti condiviso, la modifica viene rilasciata una volta sola e arriva ovunque. Ogni dispositivo che aggiungi rende quella differenza ancora più grande.
Cos’è l’inversione della velocità nello sviluppo di piattaforme OTT?
È il momento in cui il broadcaster che ha lanciato più velocemente diventa quello che rilascia più lentamente.
È la parte che coglie di sorpresa i direttori tecnici. Il white-label ti mette live in settimane. 18 mesi dopo, ogni modifica che vuoi apportare passa per il backlog del fornitore e arriva secondo il suo calendario di rilascio, quindi procedi al loro ritmo a tempo indeterminato. Nel frattempo, il team che ha costruito la propria piattaforma ha impiegato da 12 a 18 mesi per arrivare in produzione — e poi ha iniziato a controllare il proprio orologio.
All’inizio, il compromesso vale chiaramente la pena. Sei live e il tuo competitor è ancora in sviluppo. Un anno dopo, anche il tuo competitor è live, rilascia ogni settimana, e tu stai aspettando il Q3. Fora Soft è giunta a una conclusione simile nel loro playbook build-vs-buy del 2026: per la monetizzazione ibrida tra SVOD, AVOD e FAST, un build personalizzato si ripaga entro 18-24 mesi.
Quando il white-label è ancora la risposta giusta?
Quando il catalogo è semplice e il prodotto non ha bisogno di differenziarsi.
Preferisco dirlo chiaramente piuttosto che fingere che l’alternativa sia gratuita. Un build personalizzato richiede da 12 a 18 mesi per arrivare in produzione, e per un certo numero di broadcaster il white-label rimane la decisione corretta sui numeri.
Ma se stai competendo per gli stessi abbonati di Netflix, che effettua deploy in modo continuo, o di DAZN, che nel 2026 sta investendo più di 3 miliardi di dollari in diritti live e gestisce il proprio front end, la domanda diventa molto più urgente. Puoi permetterti di rispondere al tuo mercato l’anno prossimo anziché questa stagione?
Misura la tua posizione in termini di velocità delle funzionalità
L’unico numero da iniziare a monitorare
La velocità delle funzionalità si riduce a una singola questione di proprietà: se controlli la pipeline, rilasci quando il mercato ne ha bisogno. Se non la controlli, rilasci quando il fornitore ti raggiunge.
Il broadcaster con le 2 lingue del commento la misura adesso. Ha visto una finestra di sei settimane chiudersi contro un preventivo di otto settimane e non ha mai più voluto sentirsi dire quel numero.
Se la tua risposta onesta a “quanto ci vorrebbe?” è “fammi chiedere al fornitore”, la tempistica appartiene già a qualcun altro. È una conversazione che vale la pena avere all’IBC di quest’anno, Stand 5.F51.
Domande frequenti
Come si calcola la velocità delle funzionalità per una piattaforma streaming?
Monitora due numeri: la frequenza di deploy (quanto spesso il codice raggiunge gli abbonati) e il lead time (giorni del calendario dall'approvazione interna alla messa in produzione di una funzionalità su tutte le piattaforme). Il report DORA 2025 colloca i team d'élite a più deploy al giorno. Se la tua risposta dipende da quando il fornitore pianifica il prossimo rilascio, stai misurando la loro velocità, non la tua.
Posso migliorare la velocità delle funzionalità su una piattaforma OTT white-label?
Entro certi limiti. Puoi snellire il tuo processo di approvazione e ridurre gli scambi sulle specifiche. Ma la pipeline di rilascio, le submission agli store, la certificazione dei dispositivi e il ciclo di QA appartengono al fornitore. Questi sono vincoli strutturali, non problemi di processo. Il soffitto è la loro architettura, e nessuna efficienza interna lo cambia.
Quando una piattaforma OTT sviluppata su misura diventa più veloce del white-label?
In genere dai 12 ai 18 mesi dopo il lancio in produzione. Prima di allora, il white-label è per definizione più veloce sul mercato. Dopo, il build personalizzato controlla il proprio ciclo di rilascio e inizia ad accumulare vantaggio ad ogni sprint. L'analisi 2026 di Fora Soft colloca il break-even finanziario tra i 18 e i 24 mesi per i modelli di monetizzazione ibrida.
