Software Custom vs SaaS: Quando Scegliere Cosa
Risposta rapida: Scegli SaaS per processi standard con soluzioni mature sul mercato. Scegli software custom quando il processo è unico per la tua azienda, quando i SaaS disponibili richiedono di adattare il tuo modo di lavorare (invece del contrario), o quando le integrazioni necessarie non sono disponibili out-of-the-box. Nelle PMI italiane l'approccio ibrido (SaaS + layer custom di integrazione) è spesso la scelta più razionale.
Cosa si intende per SaaS e software custom
SaaS (Software as a Service) è un'applicazione sviluppata da un fornitore per un mercato ampio, con funzionalità standard condivise da tutti i clienti. Si accede via browser o app, si paga un abbonamento (mensile o annuale), non si possiede il codice né l'infrastruttura. Il vendor garantisce manutenzione, aggiornamenti e disponibilità, ma definisce anche il perimetro funzionale e il pricing nel tempo.
Esempi tipici di SaaS usati dalle PMI italiane: Fatture in Cloud, TeamSystem, Aruba, HubSpot, Salesforce, Notion, Google Workspace, Microsoft 365. Sono soluzioni mature, testate da migliaia di clienti, con community ed ecosistema di estensioni.
Software custom (detto anche software su misura o bespoke software) è sviluppato specificamente per una singola azienda. Modella i processi reali dell'azienda invece di costringerla ad adattarsi a una logica imposta dall'esterno. Il committente possiede il codice sorgente, non dipende da rinnovi di licenza per continuare a operare e può modificarlo liberamente nel tempo per seguire l'evoluzione del business.
Il software custom non significa necessariamente "reinventare la ruota". I progetti custom moderni si appoggiano su framework open source consolidati, librerie pubbliche e servizi cloud (database, storage, autenticazione). La parte realmente "custom" è la logica di business specifica dell'azienda — il resto è componibilità di mattoni standard.
Tra i due esiste un approccio ibrido, sempre più diffuso: usare un SaaS maturo per la parte standard del processo (fatturazione, CRM, comunicazione) e integrare un componente custom per la logica specifica e per i flussi cross-sistema. Esempio concreto: uno studio dentistico usa un gestionale SaaS verticale per cartelle cliniche e agenda, e affianca un componente custom che orchestra promemoria multicanale (WhatsApp + email + SMS), recupero pazienti inattivi e gestione lista d'attesa. La parte clinica resta sul SaaS verticale (è il loro mestiere); la parte di engagement è custom (è il vantaggio competitivo dello studio).
Quando scegliere un SaaS
Il SaaS è la scelta giusta quando:
- Il processo è standard: fatturazione elettronica, gestione email, CRM base, prenotazioni standard, pagamenti. Questi processi sono uguali in migliaia di aziende — il SaaS li ha già risolti bene, con anni di iterazione e bug-fixing.
- Velocità di adozione è critica: un SaaS si attiva in ore o giorni. Se hai bisogno di una soluzione funzionante questa settimana, il custom non è realistico.
- Il processo è in fase esplorativa: non sai ancora esattamente come strutturarlo. Usa un SaaS per capire il processo reale prima di investire nel custom. La validazione "in produzione" su un SaaS costa una frazione di un PoC custom.
- Il team è piccolo e le risorse interne sono limitate: il SaaS include assistenza, aggiornamenti, manutenzione. Il custom richiede qualcuno che gestisca il ciclo di vita del software (interno o partner esterno).
- Il fornitore SaaS è il leader del settore: se il SaaS copre la grande maggioranza delle esigenze e la parte rimanente è marginale, adattarsi conviene.
- Il rischio operativo deve restare basso: con il SaaS, il vendor garantisce SLA, backup, security patching. Per un'azienda senza un reparto IT strutturato, scaricare questo rischio è un valore reale.
Quando scegliere software custom
Il software custom diventa la scelta giusta quando:
- Il processo è un vantaggio competitivo: se il modo in cui gestisci un processo è ciò che ti differenzia dai concorrenti, non puoi usare lo stesso software che usano tutti. Il custom protegge e accelera quel vantaggio.
- Il SaaS richiede di adattare il processo al software: se per usare il SaaS devi cambiare il tuo modo di lavorare in modo significativo, il costo nascosto (formazione, resistenza al cambiamento, inefficienze) può superare il risparmio apparente.
- Le integrazioni non esistono o sono complesse: hai sistemi legacy, verticali di settore, o combinazioni di strumenti che nessun SaaS supporta nativamente. Ogni connettore custom che aggiungi a un SaaS aumenta fragilità e costi di manutenzione.
- Il volume giustifica l'investimento: a un certo volume di utilizzo, il costo del SaaS su base annua supera il costo di sviluppo e manutenzione del custom. Questo breakeven dipende dal processo specifico e dal modello di pricing del SaaS (per utente, per transazione, per volume di dati).
- La compliance richiede controllo totale: in settori regolati (sanità, finanza, dati sensibili) il controllo su dove i dati risiedono e come vengono trattati può rendere il SaaS inadeguato o troppo costoso da adeguare.
- Stai integrando AI in modo profondo: se la tua differenziazione passa per workflow AI complessi (agenti multi-step, RAG su knowledge base proprietaria, orchestrazione di modelli), il custom è quasi sempre l'unica opzione realistica. I SaaS AI generici sono utili come building block, non come prodotto finale.
I 5 segnali che hai bisogno di software custom
Non sempre il bisogno di custom è ovvio. Ecco cinque segnali pratici che indicano che hai superato il punto in cui un SaaS è ancora la scelta razionale:
1. Hai sviluppato workaround manuali sopra il SaaS
Il team esporta dati dal SaaS in Excel, li manipola con macro o script, e poi rientra i risultati. Ogni workaround è un sintomo: il SaaS non copre il processo reale. Quando i workaround diventano critici per l'operatività, sei già oltre il limite del SaaS.
2. Paghi più SaaS che fanno cose simili
Hai accumulato strumenti diversi per gestire pezzi diversi dello stesso processo, perché nessuno copre tutto. La somma degli abbonamenti diventa significativa e la frammentazione dei dati ti costa tempo. Un layer custom che unifica può ripagarsi rapidamente.
3. Le richieste di personalizzazione al vendor restano inevase
Da mesi chiedi una feature specifica al fornitore SaaS e la risposta è "in roadmap, ma non sappiamo quando". Se quella feature è bloccante per la crescita, dipendere dalla roadmap di terzi è un rischio operativo concreto.
4. Il pricing SaaS cresce più velocemente del valore percepito
Il fornitore aumenta il prezzo ogni anno, oppure il pricing per utente/transazione scala in modo lineare mentre l'utilità marginale resta costante. A un certo punto il modello economico del SaaS non è più allineato con il tuo.
5. La logica di business è "matura e stabile"
Sai esattamente come deve funzionare il processo, le regole non cambiano ogni mese, e il SaaS ti obbliga a comprime quella logica in flussi che non rispecchiano la realtà. La maturità del processo è il prerequisito per fare custom bene.
Se riconosci due o più segnali tra questi cinque, una valutazione di fattibilità custom (o ibrida) ha senso. Se ne riconosci uno solo, prova prima a ottimizzare l'uso del SaaS attuale.
Framework decisionale: 5 domande pratiche
Prima di decidere, rispondi a queste cinque domande:
| Domanda | Risposta → SaaS | Risposta → Custom |
|---|---|---|
| Esiste un SaaS che copre la grande maggioranza del processo? | Sì | No |
| Quante integrazioni con sistemi esistenti servono? | Poche, già supportate | Diverse, o non supportate |
| Il processo cambierà molto nei prossimi 2 anni? | Non lo so ancora | È già definito e stabile |
| È accettabile adattare il processo al software? | Sì, con effort limitato | No, il processo è vincolante |
| Chi gestisce manutenzione e aggiornamenti? | Nessuno interno disponibile | Partner tecnico dedicato |
Come interpretare il risultato
Una volta risposto alle 5 domande, distribuisci le risposte nei tre scenari seguenti per capire qual è la strada più razionale per la tua situazione.
Scenario A — quasi tutto verso SaaS
Quattro o cinque risposte indicano SaaS.
Procedi con un SaaS maturo. Fai una shortlist di 2-3 candidati, conduci una trial reale con i tuoi dati e i tuoi utenti, misura il fit prima di firmare contratti annuali. Investi in onboarding e formazione: la maggior parte dei fallimenti SaaS è dovuta a scarsa adoption, non a limiti del software.
Scenario B — mix equilibrato
Le risposte sono distribuite circa metà SaaS e metà custom.
È il territorio dell'approccio ibrido. Identifica la parte standard del processo (delegabile a un SaaS maturo) e la parte che ti differenzia (da realizzare custom). Il layer custom integra i SaaS scelti e implementa la logica specifica. È il pattern più frequente nelle PMI italiane con processi mediamente strutturati.
Scenario C — quasi tutto verso custom
Quattro o cinque risposte indicano custom.
Procedi con un progetto custom, ma in modo iterativo. Inizia con un PoC mirato sulla parte di processo a maggior valore o a maggior rischio. Valuta i risultati prima di estendere lo scope. Scegli un partner che lasci ownership del codice, definisca un modello di manutenzione chiaro e accetti un go-live progressivo.
Nota: il framework è uno strumento di orientamento, non una formula meccanica. Una singola domanda con risposta molto forte (es. "il SaaS non esiste per questo settore") può ribaltare l'esito complessivo.
L'approccio ibrido: SaaS + custom integration layer
La dicotomia netta "SaaS o custom" è spesso falsa. Le PMI più efficienti usano SaaS maturi per le parti standard dei processi e aggiungono un layer custom per:
- Connettere sistemi che il SaaS non integra nativamente
- Aggiungere logica di business specifica (validazioni, approvazioni, routing)
- Unificare dati da più SaaS in un'unica vista operativa
- Automatizzare workflow cross-sistema che richiedono coordinamento tra più applicazioni
- Esporre dashboard e KPI specifici per il management
- Implementare logica AI proprietaria sopra dati standard del SaaS
Esempio pratico: SEPA Manager usa Fatture in Cloud come SaaS per la fatturazione (non lo reinventa) e aggiunge il layer custom per la generazione XML SEPA e la sincronizzazione bancaria — la parte che nessun SaaS generalista copre bene. Il risultato è una soluzione che eredita la maturità del SaaS e aggiunge la specificità che il mercato richiede.
Errori comuni nella scelta tra SaaS e custom
Cinque errori che vediamo ripetersi nelle PMI italiane quando affrontano questa decisione, e come evitarli.
Errore 1 — Scegliere prima di mappare il processo
Cosa succede: il team valuta strumenti senza una mappa chiara del processo "as-is". Il SaaS scelto sembra coprire tutto in demo, ma in produzione emergono i gap. Il custom commissionato cresce di scope in corso d'opera perché requisiti reali emergono troppo tardi.
Come evitarlo: prima di valutare qualsiasi strumento, mappa il processo end-to-end (input, attori, decisioni, output, eccezioni). Anche un diagramma su carta vale più di una shortlist di SaaS fatta a freddo.
Errore 2 — Valutare solo il costo iniziale
Cosa succede: il SaaS sembra economico perché si confronta l'abbonamento mensile con l'investimento iniziale del custom. Si ignora che l'abbonamento accumula nel tempo, che il pricing per utente cresce, e che alcuni SaaS introducono limiti che obbligano upgrade a tier superiori.
Come evitarlo: calcola sempre il TCO su almeno 3 anni (meglio 5). Includi tutti i costi: licenze, integrazioni, formazione, manutenzione, evoluzioni future, cost-of-switching futuro.
Errore 3 — Sottovalutare l'adoption del SaaS
Cosa succede: il SaaS viene attivato ma il team continua a usare gli strumenti vecchi in parallelo, o usa solo una frazione delle funzionalità. L'investimento non genera il valore atteso, ma il problema non è il SaaS — è la mancata gestione del cambiamento.
Come evitarlo: nomina un owner interno del SaaS. Dedica tempo strutturato all'onboarding (non solo la demo iniziale). Misura l'adoption nei primi 3 mesi e correggi se necessario.
Errore 4 — Ignorare le integrazioni con sistemi esistenti
Cosa succede: la decisione tra SaaS e custom viene presa isolando il nuovo strumento dal resto dello stack. In produzione si scopre che servono integrazioni con gestionale, CRM, banca, e che il SaaS scelto non le offre — oppure le offre solo nel piano enterprise più caro.
Come evitarlo: elenca tutti i sistemi adiacenti che dovranno parlare con il nuovo software. Verifica documentazione API, eventuali connettori nativi, costi di integrazione. È un fattore che può ribaltare la decisione.
Errore 5 — Non definire chi mantiene il custom dopo il go-live
Cosa succede: il software custom viene rilasciato e nei mesi successivi nessuno ha la responsabilità di manutenzione evolutiva, bug-fixing, security patching. Il software invecchia, accumula debito tecnico, e dopo 2-3 anni serve un re-write.
Come evitarlo: definisci il modello di manutenzione prima dell'inizio del progetto. Le opzioni tipiche sono: contratto di manutenzione annuale con il partner che ha sviluppato, internalizzazione delle competenze, o partner di terze parti dopo handover documentato. Tutte sono accettabili — l'assenza di scelta no.
Domande da fare al fornitore custom prima di firmare
Un fornitore serio risponde con sicurezza e dettaglio a queste domande. Esitazioni o risposte generiche su uno qualunque di questi punti sono un segnale di rischio.
-
Chi possiede il codice sorgente alla fine del progetto?
La risposta corretta è: il committente. Verifica che sia scritto nel contratto. Se il codice resta del fornitore, il vincolo verso di lui diventa permanente (lock-in da fornitore, non più da SaaS).
-
Qual è il modello di manutenzione post go-live e a che costo?
Dovrebbe esistere un'offerta di manutenzione annua chiara, con perimetro definito (bug-fix incluso, evoluzioni a parte). Senza un modello esplicito di manutenzione, il rischio è ritrovarsi con un software orfano dopo 12 mesi.
-
È prevista una fase di PoC prima dell'impegno completo?
Per progetti non banali, un PoC mirato sulla parte più rischiosa o di maggior valore riduce il rischio di entrambe le parti. Un fornitore che salta direttamente al "tutto e subito" sta sottovalutando il progetto, oppure ha un interesse a chiudere prima di mostrare difficoltà.
-
Come gestite lo scope creep?
Le richieste cambiano sempre durante lo sviluppo. Il fornitore deve avere un processo chiaro per gestire varianti: change request scritte, valutazione di impatto su tempi e costi, decisione del committente. "Vediamo strada facendo" non è una risposta accettabile.
-
Quale stack tecnologico viene usato e perché?
Il fornitore deve poter motivare le scelte (linguaggi, framework, database, hosting) in base ai requisiti del progetto, non perché "è quello che usiamo sempre". Stack ragionati implicano manutenibilità e disponibilità di competenze sul mercato.
-
Come gestite test e qualità del codice?
Aspettati menzioni a test automatici, code review, ambienti separati (dev/staging/prod), CI/CD. L'assenza di pratiche di engineering moderne è un indicatore di software fragile destinato a invecchiare male.
-
Qual è il piano di handover (documentazione, formazione)?
Documentazione tecnica del software, documentazione operativa per gli utenti, formazione per chi userà il sistema e per chi (eventualmente) ne ereditare la manutenzione. Un handover serio dura settimane, non un pomeriggio.
-
Come gestite security, backup e disaster recovery?
Dipende dalla criticità del software, ma vanno indirizzati esplicitamente: dove risiedono i dati, come sono protetti, qual è la strategia di backup, qual è il tempo di ripristino atteso in caso di incidente. Particolarmente rilevante se si trattano dati personali o regolati.
Come valutare il TCO: esempio ipotetico
Il TCO (Total Cost of Ownership) è il costo totale di proprietà di un software su un orizzonte temporale definito, tipicamente 3-5 anni. Confrontare SaaS e custom solo sul costo iniziale è fuorviante: la struttura dei costi è completamente diversa.
Schema di calcolo TCO su 3 anni per un ipotetico software che gestisce un workflow operativo interno (es. gestione richieste interne, validazioni multi-step, reporting):
| Voce di costo | Opzione SaaS (esempio) | Opzione Custom (esempio) |
|---|---|---|
| Investimento iniziale | Setup, configurazione, migrazione dati | Sviluppo, design, testing, deploy |
| Costi ricorrenti anno 1 | Abbonamento per utente × utenti | Manutenzione evolutiva + hosting |
| Costi ricorrenti anno 2 | Abbonamento + eventuali aumenti listino | Manutenzione (tipicamente in % dell'iniziale) |
| Costi ricorrenti anno 3 | Abbonamento + nuovi tier obbligatori | Manutenzione + 1-2 estensioni richieste |
| Integrazioni con sistemi esistenti | Connettori nativi o middleware | Incluse nella logica del software |
| Formazione e adoption | Onboarding utenti + training periodico | Formazione iniziale + documentazione |
| Costo di switch a fine periodo | Estrazione dati, migrazione a nuovo strumento | Asset di proprietà, evolvibile o dismettibile |
| Asset residuo a fine 3 anni | Nessuno (sottoscrizione termina) | Codice sorgente, documentazione, know-how |
La logica del confronto: il SaaS ha un costo iniziale basso ma un flusso di costi ricorrenti continuo e potenzialmente crescente; il custom ha un investimento iniziale più alto ma costi ricorrenti tipicamente più contenuti (manutenzione) e produce un asset di proprietà. Il punto di breakeven cambia in funzione del numero di utenti, della stabilità del processo, dei costi orari di sviluppo nel mercato di riferimento.
Per un'analisi TCO seria per la tua situazione specifica, è consigliabile coinvolgere sia il fornitore SaaS sia il potenziale partner custom per ricevere preventivi reali e modellare lo scenario con i tuoi numeri (utenti, transazioni, integrazioni richieste).
Red flag: quando un preventivo custom è sbagliato
Diffida di un fornitore di software custom se:
- Non ti chiede di mappare il processo prima di fare un preventivo
- Propone custom per qualcosa che un SaaS maturo già fa bene (es. "ti facciamo noi il gestionale di fatturazione")
- Non prevede un PoC prima dello sviluppo completo per progetti non banali
- Non ti lascia il codice sorgente alla chiusura del progetto
- Il preventivo non specifica chi fa manutenzione dopo il go-live e a quale costo
- Non vuole confrontarsi con il tuo team tecnico interno (o con un advisor terzo)
- Stima i tempi senza chiedere dettagli sulle integrazioni o sui volumi reali
- Promette zero rischi e zero varianti di scope durante lo sviluppo
Domande Frequenti
Quando conviene sviluppare software custom invece di usare un SaaS?
Software custom conviene quando il processo da gestire è unico per il tuo settore, quando il SaaS richiede di adattare il processo all'applicazione (invece del contrario), quando hai necessità di integrare sistemi esistenti non supportati, o quando il volume d'uso rende il TCO del SaaS superiore all'investimento in sviluppo su un orizzonte di 3-5 anni.
Quando è meglio scegliere un SaaS?
SaaS è preferibile per processi standard già coperti da soluzioni mature, quando la velocità di adozione è critica, quando il processo è in fase esplorativa e non ancora consolidato, o quando il team non ha risorse per gestire un progetto software nel lungo periodo.
Il software custom costa più del SaaS?
Nel breve periodo sì. Nel lungo periodo dipende dal volume di utilizzo, dal numero di utenti e dalla longevità del software. Calcola sempre il TCO (Total Cost of Ownership) su 3-5 anni includendo: abbonamenti SaaS annui × anni, vs investimento iniziale custom + manutenzione annua stimata. La risposta cambia molto da caso a caso.
È possibile combinare SaaS e software custom?
Sì, l'approccio ibrido è il più comune nelle PMI mature: si usa un SaaS per la parte standard del processo e si aggiunge un layer custom per logica specifica e integrazioni. Questo bilancia velocità di adozione e flessibilità operativa.
Cosa fare se il SaaS non copre il 100% del processo?
Tre opzioni: (1) accettare il gap se è marginale; (2) integrare il SaaS con un componente custom che copre la parte mancante — approccio ibrido spesso ottimale; (3) sviluppare tutto custom se il gap è strutturale. La scelta dipende da quanto il gap impatta l'efficienza e dalla disponibilità di API del SaaS.
Quali sono gli errori più comuni nella scelta tra SaaS e custom?
Gli errori più frequenti sono: scegliere prima di mappare il processo, valutare solo il costo iniziale ignorando il TCO, sottovalutare l'adoption del SaaS, ignorare le integrazioni con sistemi esistenti, non definire chi mantiene il custom dopo il go-live. Mappare il processo end-to-end prima di qualsiasi decisione è la singola contromisura più efficace.
Quali domande devo fare al fornitore di software custom prima di firmare?
Le domande chiave sono: chi possiede il codice sorgente, qual è il modello di manutenzione post go-live e a che costo, è prevista una fase di PoC, come viene gestito lo scope creep, qual è lo stack tecnologico e perché, come vengono gestiti test e qualità, qual è il piano di handover, come sono gestite security e backup. Una risposta evasiva su una qualsiasi di queste è un red flag.
Come calcolo il TCO di un software su 3 anni?
Per il SaaS: abbonamento annuo per utente × numero utenti × anni, più costi di integrazione, formazione, eventuali consulenze, costo di switch a fine periodo. Per il custom: investimento iniziale di sviluppo + manutenzione annua (tipicamente in % dell'iniziale) + hosting + estensioni nel tempo. Il confronto va fatto sullo stesso orizzonte temporale, includendo i costi nascosti di adattamento del processo.
Synaptica Solution — Valutazione Custom vs SaaS
Non sai se il tuo processo richiede sviluppo custom o un SaaS già disponibile? Il team di Synaptica Solution ha analizzato processi in sanità, finanza, e-commerce e servizi professionali. In 30 minuti di discovery call valutiamo insieme le opzioni SaaS disponibili, il TCO reale e la fattibilità di un progetto custom — senza impegno, senza richiedere un capitolato tecnico preventivo.
Prenota la valutazione gratuitaNon sai se il tuo caso vuole SaaS o custom?
Chiamata conoscitiva di 30 minuti: descrivi il processo, analizziamo i SaaS disponibili, valutiamo la fattibilità custom e ti diciamo quale approccio ha senso per la tua situazione specifica. Nessun impegno, nessuna carta richiesta.
Prenota la chiamata conoscitiva (30 min)Fonti e riferimenti
Le considerazioni espresse in questa guida si basano sull'esperienza diretta di Synaptica Solution nello sviluppo di software custom e nell'integrazione di SaaS per PMI italiane (settori sanità, professionale, e-commerce, finanza). Per terminologia tecnica di riferimento si rimanda a fonti pubbliche stabili come Software as a Service e Custom software (Wikipedia, voci enciclopediche aggiornate). Per approfondimenti tecnici su pattern architetturali e integrazione consigliamo la documentazione pubblica dei principali vendor cloud (AWS, Azure, Google Cloud), accessibile dalle rispettive sezioni di "Architecture Center".