“Lo costruiamo o lo compriamo?” è una delle domande che i clienti mi pongono più spesso, e raramente è semplice come chi la fa spera. Compra il SaaS sbagliato e passi anni a combattere i suoi limiti; costruisci la cosa sbagliata e ti ritrovi un fardello di manutenzione che sopravvive alle persone che l’hanno scritto. Ecco il framework che uso per rendere la scelta difendibile.
Parti da una domanda: è un elemento differenziante?
La lente più utile in assoluto: questa capacità differenzia il tuo business, o è un requisito di base?
- Differenziante — qualcosa per cui i clienti ti scelgono, o un processo che è davvero il tuo vantaggio → propendi per build (o personalizzazione spinta). Non vuoi che il tuo vantaggio competitivo sia una casella che un vendor potrebbe dare a tutti domani.
- Commodity — invio email, CRM, autenticazione, pagamenti, HR → propendi per buy. Costruire infrastruttura non differenziante è spendere i tuoi migliori ingegneri su un problema già risolto.
La maggior parte delle cose sono commodity. Sii onesto su quanto poche delle tue capacità siano davvero differenzianti.
Le domande che affinano la decisione
- Total cost of ownership, non il prezzo di listino. Comprare ha costi di licenza + integrazione + lock-in. Costruire ha costi di build + manutenzione per sempre + il costo-opportunità del team. Confronta su 3-5 anni, non all’acquisto.
- Time-to-market. Il buy di solito vince sulla velocità. Se essere live questo trimestre conta più del fit perfetto, è un segnale forte.
- Fit. Quanto del tuo requisito reale copre il prodotto out-of-the-box? 80% con punti di estensione puliti è ottimo. 80% dove il 20% mancante è il tuo workflow core è una trappola.
- Team e longevità. Riesci a mantenere ciò che costruisci, per anni, man mano che le persone se ne vanno? Un brillante sistema custom che nessuno sa mantenere è una passività, non un asset.
- Controllo strategico & lock-in. Quanto è doloroso lasciare il vendor in seguito? Per le capacità core, il costo di uscita è un rischio reale da soppesare.
La via di mezzo che quasi tutti dimenticano
Raramente è puro build vs puro buy. La risposta matura è spesso compra la piattaforma, costruisci il differenziante sopra:
- Compra il motore di commerce, costruisci l’esperienza di storefront che è il tuo vantaggio.
- Compra la piattaforma di marketing, costruisci le integrazioni custom e la logica dati che la rendono tua.
- Compra le primitive cloud, costruisci l’orchestrazione specifica del tuo business.
È esattamente il pattern Salesforce-più-custom in cui lavoro ogni giorno: piattaforme standard per la commodity, architettura custom per le parti che differenziano. Ottieni velocità e un fossato difensivo.
Le trappole da ciascun lato
Over-buying: assemblare così tanti strumenti SaaS che il tuo vero sistema diventa il fragile layer di integrazione tra loro — che ora mantieni comunque, senza nessuno dei vantaggi di controllo.
Over-building: l’illusione del “siamo speciali” che porta i team a ricostruire infrastruttura commodity, per poi passare anni a mantenere una versione peggiore di ciò che avrebbero potuto comprare.
Entrambe nascono dal saltare la domanda sul differenziante.
Come lo riassumerei a un CIO
Compra la commodity, costruisci il differenziante, e sii spietatamente onesto su quale sia quale. Decidi sul costo totale a cinque anni, pesa time-to-market e fit, e non costruire mai qualcosa che non puoi mantenere una volta che il team originale se n’è andato.
La decisione build-vs-buy non è davvero tecnica — è strategica. Riguarda dove spendi la tua scarsa capacità ingegneristica e dove sei disposto ad accettare la roadmap di qualcun altro. Azzecca questa cornice e la risposta specifica di solito diventa ovvia.