Cos'è la decisione build vs buy?

Build vs buy è la decisione su come procurarsi un software: costruirlo su misura con un team interno o esterno, comprarlo come prodotto o licenza già pronta, oppure una via intermedia che integra un pacchetto esistente con moduli custom dove serve davvero differenziarsi. Per anni è stata trattata come una scelta binaria, con il costruito percepito come più controllabile e il comprato come più rapido da attivare, ma quella cornice a due opzioni nasconde il vero rischio, che non è tecnico ma di allocazione del capitale su anni. Gartner la inquadra oggi come un continuum a tre esiti, comprare, costruire, integrare, da valutare caso per caso in base a quanto quella capacità è realmente distintiva per l'azienda. La posta in gioco è alta perché, secondo un sondaggio Gartner del 2024 su iniziative digitali in generale, solo il 48% raggiunge o supera gli obiettivi di business previsti.

Il framework buy, build, blend

Il framework di Gartner sposta la domanda da quale opzione sia migliore in assoluto a quale delle tre serva per quella capacità specifica. Comprare conviene quando la funzione è un commodity, cioè non distingue l'azienda dai concorrenti: contabilità, gestione presenze, un CRM standard. Costruire conviene quando la capacità è il vantaggio competitivo stesso, quello che un concorrente non può replicare comprando lo stesso pacchetto. Integrare, il blend, è la via più comune nella pratica reale e la più trascurata nelle discussioni informali: si parte da una piattaforma esistente e si costruisce solo lo strato che genera davvero differenziazione, lasciando al fornitore tutto il resto.

Un esempio enterprise: il TCO a cinque anni

Un esempio enterprise aiuta a rendere concreto il calcolo. Una PMI italiana con 80 dipendenti valuta un nuovo modulo di gestione ordini legato al proprio ERP verticale. Questa è una simulazione illustrativa con cifre di stima, non una statistica di mercato: serve a mostrare il metodo di calcolo del TCO a cinque anni, non a fissare un prezzo di riferimento. Opzione buy: licenza SaaS a 30.000 euro l'anno, più 40.000 euro di personalizzazione iniziale e 20.000 euro di integrazione con i sistemi esistenti, per un totale a cinque anni attorno ai 210.000 euro. Opzione build: sviluppo iniziale stimato in 180.000 euro con un team esterno, più una manutenzione annua che assorbe una quota significativa e ricorrente di quel costo iniziale ogni anno, per un totale a cinque anni nell'ordine dei 340.000 euro. Opzione blend: piattaforma di base a 15.000 euro l'anno più lo sviluppo del solo modulo differenziante, circa 60.000 euro una tantum e manutenzione limitata a quel modulo, per un totale intorno ai 165.000 euro. Il calcolo non dice quale opzione scegliere in assoluto: dice che il buy nasconde costi ricorrenti di canone, il build nasconde manutenzione che si ripete ogni anno del ciclo di vita, e il blend vince spesso proprio perché limita la parte costosa e continua a un perimetro piccolo e mirato.

L'antipattern buy-and-customize

Un antipattern frequente è il buy-and-customize senza piano: si compra una piattaforma quasi adatta e si personalizza pezzo per pezzo, richiesta dopo richiesta, senza un disegno di cosa restare standard e cosa differenziare davvero. Il risultato è pagare due volte, il canone della piattaforma e la manutenzione di personalizzazioni custom spesso non aggiornabili al successivo upgrade del vendor, costringendo a rifarle o a bloccare gli aggiornamenti. È la differenza tra un blend deciso in anticipo, con un confine chiaro tra ciò che il fornitore gestisce e ciò che l'azienda costruisce, e un blend accidentale, accumulato senza che nessuno abbia mai tracciato quel confine.

Perché conta per chi decide

La decisione build vs buy non si prende una volta per l'intero sistema ma capacità per capacità: il framework di Gartner serve a distinguere ciò che è commodity da comprare, ciò che è vantaggio competitivo da costruire, e ciò che merita un blend con un confine scritto fin dall'inizio. Chi valuta un'integrazione fra sistemi eterogenei, dove la scelta ricorrente è tra un iPaaS e uno sviluppo su misura, applica lo stesso ragionamento in scala più piccola. Chi si affida a un forward deployed engineer per la parte custom del blend deve avere chiaro fin dal contratto dove finisce la piattaforma standard e dove inizia il lavoro su misura, il confine che l'antipattern buy-and-customize lascia indefinito.