Quando si tratta di decidere se costruire o comprare software, il primo errore è affidarsi solo al costo di sviluppo. Un tempo la domanda era semplice: costruire un programma o acquistarlo? La scelta si basava su un unico criterio, quello economico. Oggi quell’asse è saltato: scrivere una prima versione di un software costa poco, a volte pochissimo. Il problema è che ci si è concentrati sulla domanda sbagliata.
Il vero costo di un software è possederlo
Il costo reale di un software non è mai stato scriverne il codice. È possederlo.
Possedere un software significa adottare un organismo vivente, con tutti i suoi problemi futuri: manutenzione, sicurezza, conformità a nuove norme come l’AI Act, supporto agli utenti. Nessuna di queste voci compare nella demo iniziale. Il codice che si vede all’inizio rappresenta forse il 20% del costo totale di proprietà. La domanda giusta non è più “quanto ci metto a farlo?”, ma “sono disposto a prendermi cura di questa creatura per i prossimi anni?”.
Costruire il core, comprare il context
Esiste un criterio per non sbagliare, descritto da Geoffrey Moore: la distinzione tra core e context. Il core è ciò che rende diversi, il motivo per cui un cliente sceglie un’azienda e non un’altra. Il context è tutto il resto: necessario, ma non distintivo.
La regola è semplice: si costruisce solo il proprio core, si compra tutto il context senza pensarci due volte. Fatturazione, invio di email, calendari, sistemi di autenticazione sono quasi sempre context.
Un esempio pratico della regola core context: Infinity Post
Quando è stato sviluppato Infinity Post, per esempio, è stato fatto perché incorporava un metodo specifico di lavorare sui testi, un’idea precisa di quality assurance, una procedura di pre-traduzione. Uno strumento generico non avrebbe potuto contenerla, perché nasceva da problemi propri, non da quelli del mercato. Era il core dell’azienda.
Chi copia uno screenshot di un software copia solo la superficie. Si compra un percorso di errori che qualcun altro ha già pagato. La differenza non la fa il prodotto, ma la velocità di apprendimento accumulata insieme agli utenti: sono loro a mostrare problemi che nella testa di chi sviluppa non potevano esistere. A volte comprare una soluzione esterna è la scelta giusta anche se costa di più, perché si stanno comprando anni di problemi già risolti da altri.
La trappola dei cento progetti
Questa nuova facilità di creare ha generato una trappola specifica di questa epoca, spesso alimentata da chi pontifica slogan senza aver mai gestito le conseguenze: l’idea che basti avviare cento progetti per vedere cosa funziona.
Ma cento progetti portati avanti al 20% non valgono il 20% di cento. Valgono zero. Il valore si sblocca solo al completamento. Prima, il costo di sviluppo era un filtro naturale. Adesso il filtro deve essere chi decide.
Quando costruire è la scelta giusta
Imparare a uccidere un progetto non è un fallimento. È un atto di focalizzazione.
La decisione, quindi, si riduce a quattro test. Si costruisce se:
- è il proprio core,
- incorpora un metodo che solo l’azienda possiede,
- esiste già un modo per portarlo a utenti veri,
- si è pronti a possederne i problemi per anni.
Se anche solo uno di questi test fallisce, la risposta di default è comprare, perché l’attenzione è l’unica risorsa che non si può ricomprare.
Se è una tensione che senti anche tu, scrivimi.
Takeaways
- Il costo reale nella scelta tra costruire o comprare software non è scriverlo, ma possederlo nel tempo, con tutti gli oneri di manutenzione, sicurezza e supporto
- La distinzione tra core e context guida la decisione strategica: si costruisce solo ciò che rende unici, si compra tutto il resto
- La trappola dei progetti incompleti nasce dalla facilità di sviluppo: cento progetti al 20% valgono zero, perché il valore si sblocca solo al completamento
- Uccidere un progetto non è un fallimento, ma un atto di focalizzazione necessario per proteggere la risorsa più scarsa, l’attenzione
Faqs
Qual è il vero costo nella scelta tra costruire o comprare software?
Il costo reale non è scrivere il codice, ma possedere il software nel tempo. Significa occuparsi di manutenzione, sicurezza, conformità a norme come l’AI Act e supporto agli utenti: voci che non compaiono in una demo e che possono rappresentare l’80% del costo totale di proprietà.
Cosa si intende per core e context in un software?
Il core è ciò che rende un’azienda diversa, il motivo per cui un cliente la sceglie rispetto a un’altra. Il context è tutto il resto, necessario ma non distintivo: fatturazione, invio di email, calendari e sistemi di autenticazione rientrano quasi sempre in questa categoria.
Quando conviene costruire un software invece di comprarlo?
Conviene costruire quando il software è il proprio core, incorpora un metodo che solo l’azienda possiede, esiste già un modo per portarlo a utenti veri e si è pronti a occuparsi dei suoi problemi per anni. Se anche solo uno di questi quattro test fallisce, la scelta di default diventa comprare.
Perché comprare un software può essere la scelta giusta anche se costa di più?
Perché chi copia una soluzione esterna sta comprando anni di problemi già risolti da altri. La differenza non la fa il prodotto in sé, ma la velocità di apprendimento accumulata insieme agli utenti, che mostrano problemi altrimenti impossibili da prevedere.
