Software Enterprise: Sviluppare o Acquistare? Il Framework Neutrale (Con Rubrica a 12 Punti, 2026)

Software Enterprise: Sviluppare o Acquistare? Il Framework Neutrale (Con Rubrica a 12 Punti, 2026)

Lo scorso settembre un cliente SaaS da $50M di ARR ci ha posto una domanda che costa milioni alle aziende se si risponde male: continuare con uno stack Salesforce + Tableau + Outreach da $487K nei prossimi cinque anni, oppure costruire una piattaforma revenue-ops personalizzata per $312K? La risposta "più economica" era sbagliata. Ecco il framework che abbiamo usato per capirlo: una rubrica di punteggio a 12 criteri, un modello TCO a 5 anni, e la tricotomia Buy/Build/Blend di Gartner che nessuna delle prime dieci guide build vs buy attualmente su Google si prende la briga di nominare. E sì, siamo un'agenzia di sviluppo, quindi Le diremo anche quando comprare SaaS invece di assumere noi.

Punti chiave (TL;DR):

• La maggior parte dei consigli build vs buy proviene da vendor che guadagnano da una sola risposta. Identifichi il bias della fonte prima di fidarsi.
• Il framework Buy/Build/Blend di Gartner copre ora il 76% della spesa software enterprise. Il puro build o il puro buy è il caso minoritario nel 2026.
• Valuti la decisione su 12 criteri ponderati, non sull'istinto. Il custom build vince con un totale >45; il SaaS vince sotto 30.
• Gli agenti di coding AI (Cursor, Claude Code) hanno ridotto le ore-ingegnere per funzionalità del 40–60% nel 2026. La matematica del build è cambiata.

Cos'è la Decisione Build vs Buy nel Software Enterprise?

La decisione build vs buy è la scelta tra acquisire in licenza software SaaS o COTS esistente (buy), sviluppare software personalizzato internamente (build), o ingaggiare un'agenzia partner per costruire software proprietario (partner). Il framework moderno di Gartner estende questo concetto a Buy/Build/Blend, e il 76% della spesa software enterprise scorre ora in combinazioni di prodotti standard ed estensioni personalizzate, non in build o buy puri.

La decisione dipende da tre domande:

• La funzionalità è un differenziatore competitivo o una commodity?
• Qual è il vero TCO a 5 anni di ciascun percorso?
• Si dispone di un team di ingegneri senior in grado di gestirla nel lungo termine?

Attenzione: Techsy è un'agenzia di sviluppo. Guadagnamo quando si costruisce. Quindi Le illustreremo tutti i casi in cui dovrebbe comprare SaaS invece di assumere noi, perché sul lungo periodo contenuti come questo funzionano solo se la matematica è onesta. Il nostro obiettivo di conversione è indicato in fondo; tutto il resto è il framework, non il pitch.

La maggior parte delle guide build vs buy è scritta da chi guadagna da una delle due risposte. I marketplace SaaS vogliono che si compri. Le agenzie di sviluppo vogliono che si costruisca. I vendor COTS vogliono che si faccia qualsiasi cosa protegga il loro rinnovo. Ne legga tre e otterrà tre raccomandazioni opposte e sicure di sé, ognuna sepolta sotto un gancio commerciale. Se sta valutando specificamente un build di voice AI, abbiamo scritto una versione verticale di questo framework che applica la stessa logica a una decisione più circoscritta. Il resto di questo post è il framework generale di procurement che può concretamente usare in una riunione.

Cosa Dice Davvero Gartner: Il Framework Buy / Build / Blend

Il framework di procurement di Gartner rifiuta la domanda binaria build vs buy e la sostituisce con una decisione a tre vie: Buy (licenza COTS o SaaS), Build (sviluppo custom interno), o Blend (combina SaaS per i flussi di lavoro commodity con codice personalizzato per quelli differenziati). Secondo il modello Buy/Build/Blend di Gartner, il 76% della spesa software enterprise scorre ora in stack ibridi. Il build o buy puro è il caso minoritario.

Buy = Acquisire in Licenza Ciò che è Commodity

Si acquisti quando la funzionalità è un problema risolto e qualcun altro ha già distribuito la soluzione su larga scala. CRM, payroll, email, gestione spese, osservabilità. L'economia dell'acquisto è migliore quando si hanno meno di 100 utenti sul flusso di lavoro, si ha bisogno di andare live in meno di 90 giorni, e il SaaS soddisfa più dell'80% delle esigenze out of the box.

Build = Possedere Ciò che è Differenziato

Si costruisca quando la funzionalità è il proprio moat. L'elemento per cui i clienti scelgono la propria azienda. Stripe non ha preso in licenza uno stack di pagamenti. Figma non ha preso in licenza un motore di rendering. Il build vince anche quando un SaaS non riesce letteralmente a modellare la propria struttura dati (si pensi a finanza multi-entità complessa o regimi di compliance inusuali) o quando il conto SaaS a 5 anni su scala supera il TCO del build personalizzato di 2 volte o più.

Blend = La Matematica con cui la Maggior Parte delle Aziende Finisce

Il blend significa mantenere COTS per l'80% di attività ordinarie e costruire custom per il 20% differenziato. Il pattern classico: Salesforce come sistema di record + un livello custom sottile per i flussi di lavoro che Salesforce non riesce a modellare correttamente. Thoughtworks chiama questo Buy/Build/Partner; Gartner lo chiama Buy/Build/Blend. Stessa idea, vocabolario leggermente diverso. La tricotomia risale alla Make-or-Buy Matrix di McKinsey degli anni '90, ma l'era cloud ha reso la terza opzione dominante.

La Rubrica di Punteggio a 12 Criteri (La Copi in un Foglio di Calcolo)

Valuti ogni criterio da 1 a 5 in base a quanto si applica alla propria situazione. Moltiplichi per il peso. Sommi i totali. La legenda delle soglie in fondo indica quale percorso suggerisce la matematica. La usi in una vera riunione di procurement e ridurrà il dibattito da due ore a venti minuti.

Legenda delle soglie:

• Totale <30 → Acquisti SaaS
• Totale 30–45 → Blend
• Totale >45 → Costruisca

Esempio pratico con il nostro cliente del caso studio (quello che esaminiamo in dettaglio nell'H2 #8): ha ottenuto 38. Il differenziatore era 3 (le revenue ops sono importanti ma non sono il loro moat), il team era 2 (non potevano dedicare ingegneri a lungo termine), il gap SaaS era 4 (Salesforce non copriva circa un terzo dei loro flussi di lavoro), la riduzione costi AI era 5. Risultato: saldamente in territorio Blend, che è dove è atterrata la raccomandazione.

Una precisazione. La rubrica è un ausilio decisionale, non un decisore. Se il punteggio è al limite (28–32 o 43–47), esegua il modello TCO nella sezione successiva prima di impegnarsi. I numeri cambiano il verdetto.

Modello TCO: Come Calcolare Onestamente il Costo a 5 Anni

Secondo la ricerca Gartner sull'analisi dei costi software, le aziende mancano il 50–70% del TCO quando calcolano la proprietà del software. Le voci più trascurate: integrazione, FTE amministrativo e costo di uscita. Il prezzo iniziale del primo anno è la parte più piccola del conto, e quasi ogni demo del vendor fornisce esattamente quel numero.

Ecco come calcolare il TCO onesto a 5 anni per ciascun percorso.

Voci di costo Buy (SaaS): licenza × utenti × anni, implementazione e configurazione, formazione, allocazione FTE amministrativo (tipicamente 0,5–2 FTE a scala enterprise), integrazione con i sistemi esistenti e costo di uscita quando si migra via.

Voci di costo Build (Custom): sviluppo iniziale (mesi-ingegnere × tariffa fully-loaded), manutenzione annua (regola empirica di settore: 15–20% del costo di build iniziale), infrastruttura e strumenti, e costo opportunità della capacità ingegneristica che si sta impegnando.

Voci di costo Blend: l'abbonamento SaaS per il livello commodity, più il costo di integrazione/estensione custom, più la manutenzione del livello custom. Meno costoso inizialmente rispetto al full build, meno oneroso continuativamente rispetto al full buy.

Si utilizzi $230K come costo fully-loaded di un ingegnere sulla costa USA: il mediano BLS era $130.160 a maggio 2024, aggiungendo ~30% per i benefit e ~25% per l'overhead. Si aggiusti ±30% per la propria area geografica. I team europei operano tipicamente il 20–30% in meno; i team USA non costieri il 15–20% in meno.

Intervalli illustrativi generici. I suoi numeri differiranno; le categorie no.

Quando Scegliere il BLEND (Il Percorso Intermedio che la Maggior Parte delle Aziende Finisce per Prendere)

Il blend vince quando né il buy puro né il build puro si adattano chiaramente al proprio flusso di lavoro. Si mantiene COTS per i livelli commodity (CRM, fatturazione, identità, osservabilità) e si costruisce custom per i flussi di lavoro che sono il proprio differenziatore competitivo o semplicemente impossibili da modellare nel SaaS. Il collante tra di loro sono le API, i server MCP o i workflow engine low-code.

Quattro pattern blend concreti che vediamo ripetutamente:

1. Salesforce + livello RevOps custom. Salesforce rimane il sistema di record. Il livello custom gestisce i flussi di lavoro revenue multi-step che il process builder di Salesforce non riesce a modellare correttamente. Il caso studio del cliente di seguito è esattamente questo pattern.
2. SAP/NetSuite + livello dati custom. Si mantiene l'ERP per libro mastro e procurement. Si costruisce un warehouse + dashboard custom per le analisi finanziarie che il proprio CFO vuole davvero.
3. HubSpot + pipeline di arricchimento custom. Si usa HubSpot per le sequenze e il CRM, ma si costruisce la propria pipeline di arricchimento quando i vendor di dati commerciali non sono abbastanza accurati sul proprio ICP.
4. HR COTS + automazione workflow custom. BambooHR o Rippling per i record, n8n o codice custom per l'orchestrazione di onboarding + offboarding che nessuno pacchettizza bene.

Il blend è diventato materialmente più economico nel 2026 perché aggiungere funzionalità AI in modo incrementale a un SaaS esistente non richiede più un team di ricerca, e i server MCP che permettono di collegare SaaS e codice custom comprimono il costo di integrazione che storicamente rendeva i blend costosi. Il blend non è un compromesso. È la risposta per il 76% delle aziende, secondo Gartner.

Quando Costruire (3 Scenari in cui il Custom Vince)

Il build vince in tre scenari chiari. Se nessuno di essi descrive la propria situazione, probabilmente non si dovrebbe costruire.

1. La Funzionalità è il Proprio Differenziatore Competitivo

Se i clienti la scelgono per questa specifica funzionalità, non può prenderla in licenza da un vendor i cui altri clienti sono i suoi concorrenti. Stripe non ha preso in licenza uno stack di pagamenti. Notion non ha preso in licenza un motore documentale. La funzionalità deve essere il moat, non solo una caratteristica che si usa.

2. Il SaaS non Riesce a Modellare la Propria Struttura Dati Unica

Se i propri dati hanno una struttura che i SaaS esistenti non riescono letteralmente a rappresentare (finanza multi-entità complessa, schemi normativi inusuali, stato multiplayer in tempo reale), spenderà di più in tariffe di personalizzazione e ore di consulenza di quanto non costerebbe costruire da zero. Lo verifichi facendo fare un POC a pagamento a due vendor SaaS. Se entrambi falliscono, costruisca.

3. Il TCO SaaS a 5 Anni Supera il Build Custom di 2 Volte o Più

La matematica si capovolge sull'utilizzo. 500 utenti su un SaaS a $200/posto/mese = $1,2M/anno = $6M in 5 anni. Un build custom mirato per lo stesso flusso di lavoro potrebbe attestarsi a $400K iniziali + $80K/anno di manutenzione = $800K in 5 anni. Quando il multiplo è 2x o più e il flusso di lavoro è stabile, si costruisca.

Avvertenza onesta: costruire significa assumersi il rischio di progetto. Il CHAOS Report del Standish Group mostra che il 69% dei progetti IT fallisce parzialmente o completamente. Costruire non è gratuito anche quando la matematica lo suggerisce. Lo si mitighi con disciplina di scope, vera ownership del prodotto e un MVP anticipato. Per gli strumenti AI interni in particolare, il software AI enterprise self-hosted è un pattern di build che vediamo funzionare nel 2026 dove le opzioni off-the-shelf non soddisfano i requisiti di residenza dei dati.

Quando Acquistare (E i Costi Nascosti di cui Nessuno Parla)

Il buy vince quando la funzionalità è commodity, si ha bisogno di andare live velocemente e il SaaS risolve la maggior parte delle proprie esigenze out of the box. Tre scenari:

1. La Funzionalità è Commodity

CRM, email, contabilità, osservabilità, identità, gestione spese. Sono problemi risolti. I vendor SaaS hanno gestito migliaia di casi limite che altrimenti dovrebbe affrontare da solo. Costruire qualcuno di questi da zero nel 2026 è quasi sempre sbagliato.

2. Serve Operativo in Meno di 90 Giorni

Se il flusso di lavoro sta bloccando i ricavi e non si ha capacità ingegneristica da impegnare, si acquisti. Il costo opportunità di un build da 6 mesi rispetto a un rollout SaaS da 6 settimane supera la tariffa di licenza in quasi tutti i casi.

3. Il SaaS Risolve >80% Out of the Box

Se il debito di personalizzazione dell'ultimo 20% costa meno del premio totale SaaS, si compri. Lo si verifichi scrivendo l'elenco dei gap prima di firmare. Se i gap sono leggeri sul flusso di lavoro (impostazioni, integrazioni, reportistica semplice) va bene. Se sono pesanti, no.

I costi nascosti che nessuno mostra nella demo:

I prezzi SaaS aumentano progressivamente. Il SaaS Management Index 2025 di Zylo mostra che l'azienda media spreca circa $21M all'anno in sedi SaaS inutilizzate o duplicate. La tariffa di licenza è il primo costo, non il costo totale.

Caso Reale: Abbiamo Aiutato un Cliente SaaS da $50M a Decidere — Stack Salesforce da $487K vs Build Custom da $312K

Nel Q3 2025 un cliente SaaS B2B da $50M di ARR ci ha chiesto se espandere il proprio stack esistente Salesforce + Tableau + Outreach (TCO stimato a 5 anni: $487K) o costruire una piattaforma revenue-ops personalizzata su Next.js + Postgres + i propri strumenti pipeline (TCO stimato: $312K). Ecco la matematica voce per voce che gli abbiamo mostrato, perché l'opzione "più economica" da $312K era la scelta sbagliata per loro, e cosa hanno realizzato alla fine.

La domanda principale sembrava binaria: continuare a pagare i premi SaaS o costruire qualcosa di più economico. Le voci di costo raccontavano una storia diversa.

Sulla carta, il build vinceva di $175K. La raccomandazione è andata nell'altra direzione.

Perché il build custom "più economico" era sbagliato per loro: non disponevano di un team di ingegneri senior che potesse assorbire indefinitamente 0,5 FTE di manutenzione. L'organizzazione di ingegneria stava già sviluppando il prodotto core. Allocare il 10–15% della capacità senior alla manutenzione revenue-ops per i prossimi cinque anni significava o rallentare la roadmap del prodotto o assumere (il che avrebbe spinto il TCO Build reale oltre $800K una volta considerati i costi reali di assunzione a prezzi di mercato, non capacità assorbita). Il numero "economico" assumeva ingegneri gratuiti. Gli ingegneri non sono mai gratuiti.

Cosa abbiamo effettivamente realizzato: un Blend. Mantenere Salesforce come sistema di record. Costruire un sottile livello revenue-ops custom ($85K iniziali, quasi zero continuativi) per i 4 flussi di lavoro che Salesforce non riusciva a modellare. Il TCO netto a 5 anni si è attestato a ~$420K, tra i due numeri principali, e hanno ottenuto i flussi di lavoro di cui avevano davvero bisogno. Realizzato in 11 settimane, nessuna nuova assunzione, nessuno slittamento della roadmap.

18 mesi dopo: il livello custom è ancora in produzione, i rinnovi Salesforce sono avvenuti senza drammi e il team di ingegneria non ha dovuto reindirizzare l'attenzione alla manutenzione RevOps dopo il build iniziale. Conclusione: il Blend era la risposta giusta perché rispettava il vincolo del team ingegneristico che la matematica del Build aveva ignorato.

Numeri anonimizzati e arrotondati per accordo contrattuale. I costi assumono una finestra 2025–2030. I prezzi Salesforce riflettono gli aumenti di listino post-agosto 2025. I guadagni di produttività degli agenti di coding AI (baseline Q3 2025) già inclusi nella stima ingegneristica di $312K. Engineering fully-loaded a $230K = mediano USA-coast BLS 2024 + 30% benefit + 25% overhead, si aggiusti ±30% per la propria area geografica. Siamo un'agenzia di sviluppo. Questa era una raccomandazione reale contro il nostro stesso interesse commerciale.

Come l'AI Ha Cambiato la Matematica Build vs Buy nel 2026

Il punto di incrocio si è spostato. Gli agenti di coding AI hanno compresso le ore-ingegnere senior per funzionalità del 40–60% nelle nostre misurazioni interne su progetti cliente nel 2026. Ciò significa che una stima di build eseguita nel 2023 è materialmente sbagliata oggi. Gartner prevede che il 75% degli ingegneri software enterprise utilizzerà assistenti di codice AI entro il 2028, rispetto al 10% nel 2023, e i nostri dati di pipeline riflettono già gran parte di quella adozione in anticipo rispetto alle previsioni.

Tre cambiamenti concreti:

• I build custom da 18 mesi ora vengono consegnati in 6–8 mesi quando lo scope è mantenuto costante. Il Blend del caso studio sopra è stato consegnato in 11 settimane; lo stesso scope nel 2023 avrebbe richiesto 18–20 settimane.
• La dimensione del team per gli strumenti interni è diminuita. Operiamo regolarmente con pod da 2 ingegneri per build che necessitavano di 5 ingegneri due anni fa, perché gli agenti di coding AI come Cursor e Claude Code assorbono il codice boilerplate che prima consumava capacità mid-level.
• La stima di build da $312K del cliente del caso studio era circa il 30% inferiore rispetto a quanto sarebbe stata la stessa stima nel 2023, prima che lo sviluppo software enterprise AI-native diventasse la modalità di lavoro predefinita.

Contrappunto onesto: l'AI taglia i costi di build, ma taglia anche i costi che i vendor SaaS sostengono per rilasciare funzionalità. La pressione sui prezzi dei vendor è reale, alcuni prezzi SaaS scenderanno, e lo spostamento del punto di incrocio non è interamente unilaterale. L'effetto direzionale favorisce ancora il build (specialmente il Blend), perché la produttività ingegneristica interna si moltiplica con l'AI più velocemente di quanto non facciano i prezzi dei vendor.

Le Trappole Decisionali più Comuni (False Economie, Sunk Cost, Sindrome NIH, Ottimismo verso il Vendor)

Quattro trappole che vediamo far deragliare ripetutamente la decisione:

1. Falsa economia. Scegliere il numero più basso dell'anno 1 ignorando il TCO a 5 anni. Il caso studio sopra stava quasi andando in questa direzione. Il prezzo iniziale del primo anno è la parte più piccola del conto su qualsiasi percorso.
2. Sunk cost. Rimanere su un SaaS su cui si è cresciuti perché la migrazione sembra costosa. La migrazione è di solito più economica di altri 3 anni con lo strumento sbagliato. La calcoli.
3. Sindrome NIH (Not Invented Here). Costruire cose che dovrebbero essere acquistate perché il team di ingegneria trova il problema interessante. Un CRM non è interessante. Un processore di pagamenti non è interessante. Li compri.
4. Ottimismo verso il vendor. Credere che ogni riga della demo del vendor funzionerà nel proprio ambiente senza costo di integrazione. La demo è il caso migliore. Il suo caso è più difficile. Sconti la demo del 30% prima di confrontare.

L'errore più costoso che vediamo: scegliere il numero più basso dell'anno 1 e ignorare il costo di uscita a 5 anni.

Come Techsy Approccia le Valutazioni Build vs Buy

Techsy realizza piattaforme enterprise custom, integra SaaS in stack esistenti e fa due diligence tecnica su valutazioni COTS per clienti B2B. Il lavoro si divide approssimativamente 40/30/30 su queste tre aree.

Una valutazione build vs buy di Techsy funziona così: una chiamata di discovery di un'ora per delimitare il flusso di lavoro, eseguiamo la rubrica a 12 criteri dal vivo con Lei su un foglio di calcolo condiviso, consegniamo un modello TCO in una settimana, e inviamo una raccomandazione scritta che potrebbe dire "compri SaaS, non assuma noi." Le nostre ultime 3 valutazioni: 1 ha raccomandato il build, 1 ha raccomandato l'acquisto, 1 ha raccomandato il blend. Non abbiamo una quota. Se sta pensando in modo più ampio alla trasformazione AI aziendale, la valutazione è di solito il punto di partenza giusto. Prenoti una valutazione build vs buy gratuita di 30 minuti.

Domande Frequenti

Qual è la differenza tra build, buy e partner nel software?

Buy significa acquisire in licenza SaaS o COTS esistente. Build significa sviluppare software personalizzato internamente con i propri ingegneri. Partner significa assumere un'agenzia o un contractor per costruire software proprietario di cui si è titolari. Gartner reinterpreta questo come Buy/Build/Blend, dove il Blend combina COTS con licenza per i flussi di lavoro commodity e codice custom per quelli differenziati, coprendo ora il 76% della spesa software enterprise.

Quando si dovrebbe costruire il software invece di acquistarlo?

Si costruisca quando tre condizioni sono soddisfatte: la funzionalità è un differenziatore competitivo per cui i clienti scelgono la propria azienda, si dispone di un team di ingegneri senior in grado di gestirla per 5+ anni senza rallentare la roadmap, e il TCO SaaS a 5 anni al proprio numero di utenti supera il TCO del build custom di almeno 2x. Se una delle tre manca, blend o buy quasi sempre vince con una matematica onesta.

Quando acquistare SaaS è più economico che costruire software custom su 5 anni?

L'acquisto vince sul TCO quando si hanno meno di ~100 utenti sul flusso di lavoro, la funzionalità è commodity (CRM, email, contabilità, osservabilità), e si ha bisogno di andarlo live in meno di 90 giorni. Al di sotto di queste soglie l'abbonamento SaaS, anche con gli aumenti annuali di prezzo, risulta inferiore al costo ingegneristico fully-loaded più manutenzione più infrastruttura più costo opportunità.

Cosa dice Gartner sul build vs buy?

Gartner rifiuta il quadro binario e usa un modello a tre vie Buy/Build/Blend. I loro dati mostrano che il 76% della spesa software enterprise scorre ora in stack ibridi (COTS con licenza più estensioni custom), non in build o buy puri. Gartner riporta anche che le aziende mancano tipicamente il 50–70% del TCO reale nei calcoli iniziali, principalmente sulle voci di integrazione, allocazione FTE amministrativo e costo di uscita.

Il build vs buy è morto?

Il quadro binario è morto. La decisione a tre vie no. Chiamare la questione "build vs buy" oscura il fatto che la maggior parte delle aziende finisce per fare un blend: SaaS per i flussi di lavoro commodity, custom per quelli differenziati, collante tra loro. La decisione è viva ed è più difficile di quanto sembri, perché ora si sta scegliendo il punto di divisione, non scegliendo un lato. La inquadri come Buy/Build/Blend e la matematica diventa più chiara.

Come cambiano il coding AI (Cursor, Claude Code) la matematica build vs buy nel 2026?

Gli agenti di coding AI come Cursor e Claude Code hanno ridotto le ore-ingegnere senior per funzionalità del 40–60% nelle nostre misurazioni del 2026 su build cliente. Questo sposta il punto di incrocio: build che non tornavano nel 2023 ora tornano. Gartner prevede che il 75% degli ingegneri software enterprise utilizzerà assistenti di codice AI entro il 2028, quindi questo cambiamento è duraturo, non temporaneo. I build da 18 mesi ora vengono consegnati regolarmente in 6–8 mesi.

Qual è il costo tipico di manutenzione annuale del software enterprise custom?

La regola empirica del settore è il 15–20% del costo di build iniziale all'anno, su base continuativa. Una piattaforma custom da $300K dovrebbe preventivare $45K–$60K annuali per la manutenzione (correzione bug, aggiornamenti dipendenze, patch di sicurezza, piccoli miglioramenti). Questo esclude i lavori di funzionalità maggiori, trattati come nuovo build. Sottostimare la manutenzione è l'errore più comune nei modelli TCO di build custom.

Quali sono i costi nascosti dell'acquisto di SaaS enterprise?

I sei costi nascosti che la maggior parte delle demo saltano: vendor lock-in (6–18 mesi per cambiare), tariffe di personalizzazione e change request ($200–500/ora), creep per sede al 7–15% all'anno con la crescita dell'organizzazione, costi di integrazione ($20K–$100K per sistema connesso), costo di uscita e migrazione (3–6 mesi di lavoro ingegneristico), e aumenti di prezzo annuali al 7–15% indipendentemente dall'utilizzo. La tariffa di licenza dell'anno 1 raramente supera il 30–40% del vero costo a 5 anni.

Cos'è il total cost of ownership (TCO) per il software?

Il TCO è il costo totale a 5 anni di un percorso software, inclusi licenza o sviluppo, implementazione, formazione, integrazione, manutenzione continuativa, allocazione FTE amministrativo, costo opportunità e costo di uscita/migrazione quando si lascia. La ricerca Gartner mostra che le aziende tipicamente mancano il 50–70% del TCO reale nei calcoli iniziali. Lo calcoli prima di impegnarsi, non dopo.

Quanto deve essere grande un'azienda per giustificare la costruzione di software enterprise custom?

Regola approssimativa: ~$10M+ di ARR o ~50+ utenti sul flusso di lavoro specifico. Al di sotto di quella soglia l'abbonamento SaaS quasi sempre vince perché non è possibile ammortizzare ingegneria e manutenzione su un utilizzo sufficiente. Al di sopra, la matematica inizia a favorire build o blend, specialmente quando il flusso di lavoro è centrale alla propria posizione competitiva. Gli agenti di coding AI nel 2026 abbassano quella soglia del 20–30% rispetto alla baseline 2023.

Conclusione

Se dovesse ricordare una sola cosa di questo articolo: identifichi il bias di ogni framework che legge prima di fidarsi della raccomandazione. I vendor danno consigli da vendor. Le agenzie danno consigli da agenzie. Il suo CFO dà consigli da CFO. Ne legga tre, trovi la sovrapposizione, e si fidi di quella.

• Esegua la rubrica a 12 criteri dal vivo in una riunione. Riduce il dibattito da due ore a venti minuti.
• Calcoli il TCO a 5 anni in modo onesto. Il prezzo iniziale del primo anno non è mai la risposta.
• Scelga il Blend per impostazione predefinita se il punteggio è 30–45. La maggior parte delle aziende finisce qui comunque.

Se vuole un secondo parere sulla decisione, prenoti una valutazione build vs buy gratuita di 30 minuti. Le diremo di comprare SaaS se è la scelta giusta. È già successo. Succederà ancora.