Custom Software · Approfondimento
Custom o piattaforma: la griglia di decisione build-vs-buy
Quando costruire software su misura e quando comprare una piattaforma: una griglia di decisione basata su fit col processo, costo totale di possesso, lock-in, proprietà del dato e time-to-value.
ARCHITETTURA · BUILD-VS-BUY
Entra · Capacità da abilitare
Esce · Build / Buy / Compose
Core vs commodity (mappa del valore)
Scompone il sistema nelle sue capacità e colloca ognuna sull'asse core/commodity: separa ciò che vi differenzia sul mercato — e merita codice di proprietà — da ciò che è ormai standard e si compra al miglior fornitore.
Fit col processo
Misura quanto il vostro flusso operativo è proprietario: un processo generico con standard d'industria consolidati spinge verso la piattaforma, un flusso che è parte del vantaggio spinge verso il custom, perché qui i workaround imposti dalla piattaforma costano più del codice su misura.
TCO a 5 anni
Calcola il costo a cinque anni includendo manutenzione, integrazione e formazione — non solo licenza o preventivo iniziale — perché è dopo il go-live che si concentra la maggior parte del costo del software e cambia il verdetto.
Lock-in e diritti di uscita
Pesa il costo di uscita prima di entrare: contratti, portabilità del dato e integrazioni cablate determinano se al rinnovo avrete potere negoziale o se vi ritroverete senza leva, con un fornitore che lo sa.
Proprietà del dato
Verifica che il dato che vi distingue resti vostro, esportabile in formati standard e indipendente dal fornitore: una sola voce non esportabile può ribaltare la decisione, perché un asset trasformato in ostaggio pesa più di qualsiasi risparmio di listino.
Time-to-value
Bilancia l'urgenza del valore con la durata del vantaggio: una soluzione provata già disponibile serve a partire subito, mentre un differenziante strutturale giustifica un'implementazione più lunga e sostenuta.
I segnali che la decisione build-vs-buy è già stata presa male
La domanda non è "custom o piattaforma". È: quale capacità merita codice di proprietà e quale è una commodity da comprare. Questi sintomi indicano che la linea è stata tracciata nel punto sbagliato.
- State personalizzando una piattaforma standard fino a snaturarla: ogni release del fornitore rompe le vostre configurazioni e il "pronto all'uso" è diventato un progetto di sviluppo permanente.
- Avete costruito su misura una commodity — autenticazione, pagamenti, notifiche — spendendo capacità ingegneristica su problemi già risolti dal mercato, invece che sul vostro vantaggio competitivo.
- Il dato che vi distingue vive dentro un fornitore in un formato proprietario, senza export in standard aperti: non è più un vostro asset, è un ostaggio.
- Nessuno ha mai calcolato il costo a cinque anni : la decisione è stata presa sul prezzo di listino o sul preventivo di sviluppo, ignorando manutenzione, integrazione e formazione che pesano per la maggior parte del ciclo di vita.
- Cambiare fornitore è impensabile : contratti pluriennali, dati non portabili e integrazioni cablate hanno alzato il costo di uscita a un livello che toglie ogni potere negoziale al rinnovo.
Per CTO, COO e direzioni operative che devono decidere dove investire capacità ingegneristica e dove appoggiarsi al mercato, con criteri difendibili davanti al board.
Compra la commodity, costruisci ciò che ti distingue
La regola operativa più solida non è economica, è strategica: posizionare ogni capacità sulla mappa del valore e decidere in base a dove si trova, non in base alle preferenze di chi sviluppa. Una linea di pensiero formalizzata dal Wardley Mapping.
Core vs commodity, non gusti personali
Una capacità che vi differenzia sul mercato e che evolve velocemente merita codice di proprietà. Una capacità ormai standardizzata — la stessa per voi e per i vostri concorrenti — è un centro di costo: si compra al miglior fornitore e basta. Costruire una commodity è bruciare capacità ingegneristica su un problema già risolto.
Il fit col processo è il vero discrimine
Se il vostro flusso operativo è generico e l'industria ha standard consolidati, una piattaforma vince per velocità. Se il flusso è proprietario e parte del vostro vantaggio, la piattaforma vi costringe a workaround che, sommati, costano più del codice su misura. La piattaforma vi fa adattare al suo modello; il custom adatta il software al vostro.
Configurare non è gratis
Tra comprare e costruire esiste una terza via — configurare e integrare — ma non è neutra. Far entrare una piattaforma complessa dentro un flusso specifico, con migrazione dati e formazione, ha un costo reale prima ancora della prima transazione. La trappola è la sovra-personalizzazione: si parte dalla configurazione consigliata e si itera sui dati d'uso, non si riscrive tutto il primo giorno.
Compose: il meglio dei due mondi, con disciplina
L'approccio maturo è ibrido: capacità di mercato per le funzioni standard, connesse via API documentate, e capacità ingegneristica interna concentrata sulla parte che vi distingue davvero. È la logica composable (microservizi, API-first, cloud-native, headless): componenti sostituibili che cambiano senza far crollare tutto ciò che vi è collegato.
La decisione deve essere strutturale, non emotiva
Mappare le capacità rende la scelta leggibile: si vede dove ogni componente si trova sull'asse genesi-commodity, da cosa dipende e dove spinge l'evoluzione. Così la linea build-vs-buy smette di essere una preferenza di reparto e diventa una decisione di architettura difendibile.
Come tracciamo la linea, capacità per capacità
Non decidiamo "custom o piattaforma" per l'intero sistema. Scomponiamo il sistema in capacità e facciamo passare ognuna attraverso gli stessi gate. Il risultato è una mappa, non un'opinione.
Scomponiamo il sistema nelle sue capacità e collochiamo ognuna sull'asse core/commodity: cosa vi differenzia, cosa è ormai standard. Qui si separa ciò che vale codice di proprietà da ciò che si compra.
Per ogni capacità verifichiamo quanto il vostro flusso è proprietario. Flusso standard al 60-70% con eccezioni gestibili: si configura. Flusso che è parte del vantaggio: si costruisce. Flusso generico: si compra.
Calcoliamo il costo a cinque anni includendo manutenzione, integrazione e formazione — non solo licenza o preventivo iniziale. In parallelo misuriamo il costo di uscita: portabilità del dato, diritti di export, dipendenza dalle integrazioni.
Ogni capacità riceve un verdetto — build, buy o compose — e la sua collocazione nell'architettura. Le commodity vanno su API documentate; il differenziante diventa codice di proprietà con il dato sotto il vostro controllo.
Dalla mappa delle capacità alla griglia di decisione difendibile in poche settimane, non in un trimestre di studi.
Build, Buy o Compose: i gate di decisione
Ogni capacità passa per cinque leve. Non è una somma di punti: una sola leva può ribaltare la decisione (un dato proprietario non esportabile pesa più di qualsiasi risparmio di listino).
| Leva di decisione | Spinge verso BUY / piattaforma | Spinge verso BUILD / su misura |
|---|---|---|
| Posizione sulla mappa | Capacità commodity, identica ai concorrenti | Capacità core che vi differenzia ed evolve in fretta |
| Fit col processo | Flusso generico, standard d'industria consolidati | Flusso proprietario; la piattaforma impone workaround costosi |
| TCO a 5 anni | Manutenzione e rischio a carico del fornitore | Volumi e durata d'uso ammortizzano il costo di sviluppo |
| Lock-in & uscita | Export in standard aperti, uscita per convenienza, integrazioni via API | Il dato critico deve restare di proprietà, indipendente dal fornitore |
| Time-to-value | Serve valore subito; soluzione provata già disponibile | Il vantaggio giustifica un'implementazione più lunga e sostenuta |
I quattro asset che la griglia mette al sicuro
Una decisione build-vs-buy ben fatta non ottimizza solo il costo. Protegge ciò che, perso, non si ricompra.
Proprietà del dato
Il dato che vi distingue resta vostro, esportabile in formati standard e indipendente dal fornitore. Non un ostaggio in un silo proprietario, ma un asset negoziabile che vi dà potere al rinnovo.
Capacità ingegneristica ben spesa
Ogni ora di sviluppo va sul vostro vantaggio competitivo, non su una commodity già risolta dal mercato. Il custom dove conta, il mercato dove non conta.
Diritti di uscita
Portabilità del dato, integrazioni via API documentate e nessun cablaggio proprietario tengono basso il costo di switch. La possibilità di andarsene è ciò che vi fa restare a condizioni eque.
Architettura componibile
Capacità sostituibili e connesse via API: un componente cambia senza far crollare il resto. Il sistema resta vivo nel tempo, non un blocco monolitico da rifare.
Costruisci ciò che ti distingue, compra ciò che ti accomuna ai concorrenti.
Le domande che ci fanno prima di decidere
Custom è sempre più caro della piattaforma?
Non sul ciclo di vita. La maggior parte del costo del software arriva dopo il go-live — manutenzione, integrazione, formazione. Su una commodity la piattaforma vince perché scarica quel costo sul fornitore. Su una capacità core con volumi e durata d'uso elevati, il custom si ammortizza e il listino di una piattaforma cresce nel tempo. La risposta sta nel TCO a cinque anni, non nel prezzo d'ingresso.
Posso comprare ora e costruire dopo?
Sì, ed è spesso la mossa giusta — a condizione di non farsi intrappolare. Comprare per partire subito è sensato se il dato resta esportabile in standard aperti e le integrazioni passano da API documentate. Se invece il fornitore detiene il vostro dato in formato proprietario, "dopo" diventa una migrazione costosa che non farete mai. La portabilità si negozia alla firma, non al divorzio.
Come evitiamo di costruire qualcosa che il mercato risolve meglio?
Mappando ogni capacità prima di scrivere codice. Se una funzione è ormai standard — la stessa per voi e per chi vi compete — costruirla è capacità ingegneristica bruciata. Il codice di proprietà va riservato a ciò che vi differenzia e che evolve; tutto il resto si compra o si compone via API. È la disciplina che separa un investimento da una spesa.
Casi
Dal problema al risultato — anonimi.
La piattaforma snaturata
Problema Un retailer aveva personalizzato una piattaforma e-commerce standard fino a snaturarla: ogni release del fornitore rompeva le configurazioni e il "pronto all'uso" era diventato un progetto di sviluppo permanente, con il motore di pricing — il loro vero differenziante — incastrato dentro vincoli che non controllavano.
Metodo Abbiamo mappato le capacità sull'asse core/commodity: catalogo, checkout e pagamenti come commodity da mantenere sulla piattaforma via API documentate; il motore di pricing e promozioni, parte del vantaggio competitivo, estratto come servizio di proprietà connesso in modo componibile.
Risultato Le release del fornitore hanno smesso di rompere il sistema, la capacità ingegneristica è tornata sul pricing invece che sui workaround, e la logica che li distingue è diventata codice loro, sostituibile senza far crollare il resto.
Il dato in ostaggio
Problema Una società di servizi finanziari teneva il dato cliente che la distingueva dentro un fornitore, in formato proprietario e senza export in standard aperti: cambiare era impensabile e al rinnovo il fornitore aveva tutto il potere negoziale, perché l'uscita era di fatto preclusa.
Metodo Abbiamo applicato i gate di lock-in e proprietà del dato: rinegoziato diritti di export in formati standard alla scadenza, spostato le integrazioni critiche su API documentate e riportato sotto controllo interno il dato differenziante, lasciando le funzioni commodity dove erano.
Risultato Il costo di uscita è sceso al punto da ridare leva al rinnovo, il dato è tornato un asset negoziabile invece che un ostaggio, e la possibilità di andarsene li ha fatti restare a condizioni eque.
La commodity costruita da zero
Problema Un operatore logistico aveva costruito su misura capacità ormai commodity — autenticazione, notifiche, gestione utenti — bruciando capacità ingegneristica su problemi già risolti dal mercato, mentre la pianificazione delle rotte, il loro vero vantaggio, restava sottoinvestita.
Metodo Abbiamo fatto passare ogni capacità per la mappa del valore e il TCO a cinque anni: dismesso il custom sulle commodity sostituendolo con servizi di mercato dietro API, e concentrato gli sviluppatori sull'ottimizzazione delle rotte, dove i volumi e la durata d'uso ammortizzano il codice su misura.
Risultato Ogni ora di sviluppo è tornata sul differenziante, la manutenzione delle commodity è passata ai fornitori, e l'architettura è diventata componibile — componenti sostituibili che cambiano senza rifare il blocco intero.
Approfondisci ancora
Architettura del prodotto AI→
Dove finisce la commodity e inizia il codice di proprietà quando il sistema è AI-nativo.
RAG e grounding→
Comprare il modello, costruire il grounding sul dato che vi distingue.
Governance dell'adozione AI→
Criteri difendibili davanti al board per decidere build, buy o compose sull'AI.