English version draft — full translation in F3. Italian content preserved for technical fidelity.
Il dibattito "build vs buy" si ripresenta a ogni decisione tecnologica strategica. Il problema e' che la risposta non e' mai universale. Dipende da almeno cinque variabili: maturita' del processo, valore strategico dei dati, intensita' competitiva del settore, costo del lock-in, capacita' di assorbire complessita' interna.
In questa analisi mettiamo a fuoco i criteri di decisione che usiamo nei progetti di trasformazione digitale per le PMI italiane e per le organizzazioni della Pubblica Amministrazione che ci affidano la valutazione architetturale.
Il falso dilemma binario
La domanda "meglio SaaS o custom" e' mal posta. Le architetture reali combinano sempre componenti SaaS commodity (email, CRM di base, fatturazione SDI) con componenti custom dove risiede il vantaggio competitivo. La domanda corretta e' quale livello di customizzazione ciascun componente merita.
Un esempio concreto: una catena retail con 30 negozi puo' tranquillamente usare un SaaS per HR e contabilita' generale, ma il sistema di gestione magazzino real-time con sincronizzazione marketplace e' il loro vantaggio operativo. Quello non si compra. Si costruisce, oppure si compra e si plasma con integrazioni cosi' profonde che si finisce per pagare il SaaS come fosse custom — peggio ancora, con dipendenza dal fornitore.
Cinque criteri di decisione
I criteri che applichiamo in fase di discovery sono i seguenti.
1. Maturita' del processo. Se il processo aziendale e' standard di settore (es. contabilita' generale, gestione note spese, calendario condiviso), il SaaS e' quasi sempre la scelta corretta. Standardizzare un processo gia' standard e' un'opportunita' di efficienza, non una perdita di identita'.
2. Valore strategico dei dati. Se i dati prodotti dal processo sono input di altri sistemi proprietari (analitiche, modelli ML, dashboard executive), il custom mantiene il controllo. Un SaaS esporta i dati nei suoi schemi: ogni reportistica significativa richiede ETL fragile.
3. Intensita' competitiva. Settori commodity dove tutti usano gli stessi strumenti (assicurazioni base, retail standard, ristorazione) — SaaS. Settori dove il processo differenzia (industria 4.0, fintech, fashion-tech) — custom.
4. Costo del lock-in. Calcolare il costo di migrazione fuori dal SaaS scelto, in caso di cambiamento di strategia o di acquisizione. Se il costo di uscita supera il 30% del TCO 5 anni del SaaS, il lock-in e' rosso.
5. Capacita' interna di assorbire complessita'. Custom richiede team tecnico (interno o partner stabile), processo di manutenzione, ownership delle release. Se l'organizzazione non e' pronta, il custom diventa debito tecnico in 3 anni.
Il calcolo TCO che spesso viene saltato
Il calcolo TCO 5 anni va fatto bene. Spesso vediamo TCO custom calcolati solo sullo sviluppo iniziale, e TCO SaaS calcolati solo sul canone mensile. Entrambi sono sbagliati.
Custom corretto include: sviluppo iniziale + manutenzione evolutiva 20-30% del costo iniziale all'anno + infrastruttura cloud + costo del team o partner + costo opportunita' di feature non rilasciate.
SaaS corretto include: canone mensile per N utenti scalato su 5 anni + costo integrazioni custom (sempre presenti) + costo migrazione dati iniziali + costo formazione + costo lock-in (se cambia strategia) + limiti su feature non disponibili che generano workaround manuali.
Su 5 anni, i due TCO si avvicinano molto piu' di quanto si pensi. La scelta torna ai criteri qualitativi del paragrafo precedente.
Quando il custom e' la scelta ovvia
Ci sono casi in cui il calcolo si chiude da solo. Ne abbiamo visti diversi negli ultimi anni.
Processo cuore del business non parametrizzabile. Una PMI manifatturiera con un processo produttivo specifico, dove ogni configuratore SaaS si scontra con eccezioni costanti, finisce per spendere in customizzazioni una cifra superiore a un sistema interno. E con peggior controllo.
Integrazioni profonde con asset proprietari. Software che deve dialogare con macchinari industriali specifici, con ERP legacy ancora vivi, con database storici da non migrare — il SaaS finisce sempre per richiedere middleware custom che da solo costa quanto la soluzione completa custom.
Compliance verticale. Sanitario, finanziario, PA: i requisiti di tracciabilita', audit log, segregazione dati, conservazione decennale sono spesso incompatibili con SaaS multitenant esteri.
Quando il SaaS e' la scelta ovvia
All'opposto, ci sono casi in cui costruire custom e' un errore strategico.
Strumenti di produttivita' generali. Email, calendari, videoconferenza, gestione documentale di base. Costruire questi internamente e' uno spreco di risorse ingegneristiche che il mercato risolve da decenni.
CRM commodity per PMI. HubSpot, Pipedrive, Zoho funzionano benissimo per il 90% delle PMI. Il custom CRM ha senso solo se il processo commerciale e' parte del vantaggio competitivo.
Strumenti di settore maturi. Software gestionale per studi legali, dentistici, commercialisti: il mercato verticale ha gia' prodotto soluzioni mature. Costruire una versione custom equivale a competere con vent'anni di evoluzione di prodotto.
L'architettura ibrida che funziona
L'architettura che vediamo funzionare meglio nelle PMI italiane e' un'ibrida deliberata: SaaS commodity per il 70% dei processi non strategici, custom per il 30% che differenzia. I due livelli sono collegati da un'integration layer proprietario che mantiene il controllo dei dati.
Questa architettura ha tre vantaggi: ridurre il costo di sviluppo iniziale (non si reinventa la ruota), mantenere il controllo dei dati strategici (non finiscono in cloud di terzi), permettere di sostituire un componente SaaS senza riscrivere tutto (l'integration layer assorbe il cambio).
Errori ricorrenti nella decisione
Tre errori ricorrenti che vediamo nei progetti.
Errore 1 — Decidere sull'onda dell'entusiasmo. Un nuovo CIO arriva, dice "basta SaaS, riportiamo tutto in casa". Sei mesi dopo si rende conto che non ha il team. Oppure il contrario: arriva un consulente che vende migrazione totale al cloud SaaS senza calcolare i lock-in.
Errore 2 — Confondere personalizzazione con custom. "Lo facciamo customizzando il SaaS X" spesso porta a configurazioni cosi' complesse che il sistema diventa fragile e dipendente dal consulente. Meglio scegliere: o SaaS standard, o custom vero.
Errore 3 — Non calcolare il costo di uscita. Firmare un contratto SaaS triennale a sconto, senza piano B se la strategia cambia, e' una scommessa che si paga cara.
FAQ
Quanto costa un software custom rispetto a un SaaS equivalente?
Su 5 anni, il custom costa il 60-130% in piu' del SaaS equivalente se si calcolano solo i costi diretti. Se si calcolano i costi indiretti (workaround per limiti SaaS, costi di migrazione, lock-in), spesso si avvicinano. Per dare numeri concreti serve discovery.
Posso partire SaaS e poi migrare a custom?
Si', e' una strategia ragionevole quando il processo non e' ancora maturo. La condizione e' progettare la migrazione fin dall'inizio: scegliere SaaS che esportano dati in formati standard, mantenere il controllo del dato chiave, non firmare contratti triennali rigidi.
Quanto tempo richiede un progetto custom rispetto a un'adozione SaaS?
Un MVP custom richiede 3-6 mesi. Un'adozione SaaS richiede 1-3 mesi di configurazione + 6-12 mesi di adattamento al processo. Le due cose si avvicinano: l'illusione che il SaaS sia "plug and play" e' raramente vera.
Il software open source e' una terza via?
Si', nei settori dove esistono comunita' mature. Cosi' si ottiene controllo del codice (custom) con costo di sviluppo limitato (SaaS). Lo svantaggio e' che la manutenzione interna e' obbligatoria.
Conclusione operativa
La decisione build vs buy non e' una scelta filosofica. E' un calcolo TCO 5 anni applicato a ciascun componente, integrato dai cinque criteri qualitativi sopra. Un'analisi seria richiede 2-3 settimane di discovery con i process owner. E' un investimento di front-loading che ripaga ampiamente nei cinque anni successivi.
Per discutere il vostro caso specifico, apriamo un confronto tecnico.