Comprare software dà parità. Solo ciò che costruisce la distingue.

La domanda arriva quasi sempre dal tavolo della direzione, e viene avvolta nel costo: costruire il nostro software o abbonarci a un SaaS che già esiste? Formulata così, la risposta sembra un foglio di calcolo. Non lo è. È una domanda su dove vive il suo vantaggio. Comprare software risolve ciò che è comune e le consegna ciò che l'intero mercato ha già. Costruire su misura è per il nucleo che la distingue. Ciò che è uguale non la mette davanti a nessuno, ed è da qui che questa decisione va letta prima di leggerla dal prezzo.

Cosa si sta davvero decidendo

L'ingegnere Martin Fowler propone una divisione semplice e utile. C'è software utilitario, di cui tutti hanno bisogno e che deve solo funzionare, e c'è software strategico, quello in cui il modo in cui svolge una funzione è parte di ciò che lo rende migliore della concorrenza. La busta paga è l'esempio classico di utilitario: nessuno guadagna clienti elaborando gli stipendi in modo più ingegnoso. Ed è da qui che deriva la regola del comprare o costruire.

Since the definition of utility is that there's no differentiator, the obvious thing is to go with the package. [...] For a strategic function you don't want the same software as your competitors because that would cripple your ability to differentiate. Martin Fowler, Utility Vs Strategic Dichotomy, 2019

Non è un'idea isolata. Geoffrey Moore, in Dealing with Darwin, separa il core, ciò che crea preferenza d'acquisto, dal context, tutto ciò che è necessario fare per restare sul mercato ma che non distingue, e raccomanda di minimizzare o esternalizzare il context per liberare le persone migliori verso il core. Gartner sistema lo stesso istinto in un'architettura a tre strati: sistemi di registrazione, che durano un decennio e devono solo essere corretti; sistemi di differenziazione, che codificano ciò che l'azienda fa in modo diverso; e sistemi di innovazione, brevi, per testare nuove opportunità. Tre linguaggi, una conclusione: si compra la registrazione, si costruisce ciò che differenzia.

Comprare le dà parità, e a volte è quanto basta

Conviene dire ciò che il SaaS fa bene, perché lo fa. Per la contabilità, la posta elettronica, l'elaborazione degli stipendi o un CRM in fase iniziale, comprare è la decisione corretta e quasi sempre la più economica. Non vale la pena costruire ciò in cui la differenza non cambia nulla per il cliente. Ma c'è un prezzo che non è in fattura, e non è quello finanziario. Quando lei si abbona allo stesso strumento a cui si abbonano i concorrenti, eredita la capacità ed eredita anche i limiti. Il sistema è stato disegnato per servire mille aziende, non la sua, e la sua finisce per modellare il processo sullo strumento. In context, questo è accettabile. In core, significa consegnare la differenza a un fornitore che la vende uguale al vicino di casa.

Il prezzo di listino non è il costo

Il secondo errore è credere che il costo del SaaS sia il numero di listino. La spesa mondiale in applicazioni SaaS dovrebbe avvicinarsi ai 300 miliardi di dollari nel 2025, in aumento rispetto a poco più di 250 miliardi nel 2024, secondo Gartner. Non è il volume del mercato che conta qui, è ciò che esso nasconde dentro ogni azienda che compone quel totale.

Tre costi entrano raramente nel conto iniziale. Il primo è che il prezzo sale. L'indice di Vertice, una piattaforma che aiuta le aziende a negoziare gli acquisti di software, ha registrato un aumento medio dei prezzi del SaaS nell'ordine del 12% in un periodo di dodici mesi, contro il 6% nel 2019. È un valore con un interesse proprio, e vi ritorno subito dopo, ma la direzione è nota a chi rinnova contratti: il canone che ha sottoscritto non è il canone che pagherà tra tre anni.

Il secondo è che si paga per ciò che non si usa. Secondo l'indice di gestione del SaaS di Zylo, le aziende usano in media circa la metà, 49%, delle licenze che comprano, con uno spreco medio nell'ordine dei 18 milioni di dollari all'anno in licenze inutilizzate. Il terzo è strutturale ed è quello che si vede di meno: il SaaS è una spesa ricorrente che scala con ogni postazione e con ogni integrazione, e che continua a uscire dal conto ogni mese finché l'azienda esiste. Costruire ha un costo alto all'inizio e poi si ammortizza. Comprare ha un costo basso all'inizio e poi si somma, per sempre.

Il limite onesto di questi numeri

Qui è necessario essere rigorosi sulla forza di questa prova. Zylo vende gestione di SaaS e Vertice vende negoziazione di software: entrambe hanno interesse a far apparire grandi lo spreco e l'inflazione. Il campione di Zylo è composto da aziende che hanno già ingaggiato una gestione di SaaS, cioè chi aveva già un eccesso da controllare, e pende verso le grandi organizzazioni, il che spinge la media dei 18 milioni verso l'alto. Lo spreco di licenze è una falla di gestione, non un difetto inerente al modello, e un aumento di prezzo annunciato non è l'aumento effettivamente pagato da chi negozia. Nulla di ciò prova che comprare sia sbagliato. Prova che il costo del SaaS non è il numero di listino, e che chi decide con il numero di listino decide con informazione incompleta.

L'economia che l'intelligenza artificiale ha cambiato

C'è una ragione nuova per riaprire questa decisione nel 2026, ed è dal lato del costruire. Il lavoro di routine dello sviluppo, il codice ripetitivo, i test, l'impalcatura che si monta prima di cominciare la parte difficile, è diventato più economico. In un esperimento controllato con 95 programmatori, il gruppo con accesso a GitHub Copilot ha completato un compito il 55,8% più velocemente del gruppo senza lo strumento.

The treatment group, with access to the AI pair programmer, completed the task 55.8% faster than the control group. Sida Peng, Eirini Kalliamvakou, Peter Cihon e Mert Demirer, The Impact of AI on Developer Productivity, 2023

Il compito era costruire un server HTTP in JavaScript, un esercizio autonomo e ben definito, esattamente il tipo di lavoro che riempie le prime settimane di qualsiasi progetto. Se metà di quel lavoro diventa più rapido, il costo fisso di costruire il nucleo che la distingue si abbassa. Ciò che prima conveniva solo su grande scala comincia a convenire prima. È questo il cambiamento concreto: costruire su misura non è più un'esclusiva di chi ha una squadra di decine di persone.

Ciò che questo non prova

Questa è la parte che separa un ragionamento da un argomento di vendita, ed è la parte che taglia contro l'entusiasmo facile. Il guadagno del 55,8% è stato misurato in un compito isolato, da zero, svolto da professionisti reclutati per l'esperimento, in uno studio della stessa GitHub. Lo studio misura la velocità in un compito, non misura la qualità, la manutenzione né il risultato di un prodotto. E quando si misura precisamente l'altro caso, quello di lavorare dentro un codice grande che già esiste, il risultato si inverte.

When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025

In questo esperimento del 2025, sedici programmatori esperti hanno lavorato in repository che conoscevano da anni, su 246 compiti reali, e consentire l'IA li ha fatti impiegare il 19% in più. Il dato più scomodo non è il rallentamento, è la percezione. Gli stessi programmatori avevano previsto che l'IA li avrebbe accelerati del 24% e, dopo che l'esperimento li aveva rallentati, sono rimasti convinti che li avesse accelerati del 20%. Lo strumento fa sentire veloci, e la sensazione non coincide con il cronometro.

E costruire porta con sé un rischio, anche quando diventa più economico. Il CHAOS Report del 2020 dello Standish Group colloca il 31% dei progetti come riusciti, il 50% compromessi da tempi o budget e il 19% falliti. Il rapporto stesso è criticato dagli accademici, che sottolineano come il campione sia proprietario e come le sue definizioni, basate solo sulla precisione delle stime, distorcano i numeri, e per questo si legge per la direzione e non per il valore esatto: costruire da zero è una scommessa che si preventiva con un margine di errore, non un risparmio garantito. La conclusione onesta non è costruire tutto. È che l'IA ha abbassato il costo di costruire ciò che conta, e non la probabilità di sbagliare quando si costruisce ciò che non contava.

Dove passa la linea, nella pratica

Detto questo, la decisione cessa di essere comprare o costruire e diventa dove tracciare la linea, azienda per azienda. La risposta pratica è ibrida, e il test è una sola domanda: questo sistema codifica ciò che fa sì che scelgano lei? Se la risposta è no, si compra. La contabilità, la posta, gli stipendi, il CRM finché l'azienda è piccola, la videoconferenza: è context, e il context si compra pronto ed economico. Se la risposta è sì, si costruisce. Il motore operativo che nessuno sul mercato fa come lei, la logica di prezzo o di logistica che è il suo vantaggio, il rispetto di una regola specifica del suo settore che nessun pacchetto generico copre senza obbligarla a essere uguale a tutti: è core, e il core non si affitta.

C'è un segnale che decide molte di queste linee. Quando un pacchetto da scaffale la obbliga a cambiare il suo processo per rientrarvi, e quel processo è precisamente ciò che la distingue, lei sta pagando per diventare uguale alla concorrenza. In context, adattarsi allo strumento è sensato e fa risparmiare tempo. In core, significa comprare la parità che dovrebbe evitare.

Ciò che resta nel bilancio

Alla fine, la differenza tra comprare e costruire è la differenza tra una spesa e un attivo. Il software che lei compra esce dal conto ogni mese e non è suo: è una capacità in affitto, uguale a quella che il concorrente affitta nella porta accanto. Il software che codifica ciò che la distingue resta, si capitalizza e lavora per lei una volta pagato. Esistiamo per convertire la percezione in attivo finanziario, e l'architettura tecnologica che sostiene quella percezione obbedisce alla stessa regola. Ciò che è uguale non ha autorità, e ciò che è uguale non entra nemmeno nel bilancio come valore. Entra come costo ricorrente.

Fonti

Ogni numero di questo articolo è stato verificato sulla fonte primaria. Dove la fonte non sostiene la lettura corrente, lo diciamo nel corpo del testo.

1. Martin Fowler, Utility Vs Strategic Dichotomy, martinfowler.com, 2019. martinfowler.com/bliki/UtilityVsStrategicDichotomy.html
2. Geoffrey A. Moore, Dealing with Darwin (Portfolio, 2005), o modelo core vs context. en.wikipedia.org/wiki/Dealing_with_Darwin
3. Gartner, Pace-Layered Application Strategy (sistemas de registo, diferenciação e inovação). gartner.com/en/documents/3297020
4. Gartner, previsão de gasto mundial em SaaS (~250 mil milhões USD em 2024, ~300 mil milhões em 2025), via CIO Dive, 2024. ciodive.com/news/cloud-spend-growth-forecast-2025-gartner
5. Zylo, 2024 SaaS Management Index (utilização média de 49%; ~18 milhões USD de desperdício médio anual). zylo.com/news/2024-saas-management-index
6. Vertice, SaaS Inflation Index (aumento médio ~12% em doze meses, contra 6% em 2019), via CFO Dive, 2023. cfodive.com/news/saas-prices-jumped-vertice
7. Sida Peng, Eirini Kalliamvakou, Peter Cihon e Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv 2302.06590, 2023. arxiv.org/abs/2302.06590
8. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025. metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study
9. The Standish Group, CHAOS Report 2020: Beyond Infinity (31% bem-sucedidos, 50% comprometidos, 19% falhados), com a crítica de Eveleens e Verhoef, IEEE Software, 2010. resenha do relatório