In quasi ogni primo incontro che facciamo con una PMI, la domanda arriva entro il primo quarto d'ora: "quindi, quanto costa?". È una domanda perfettamente legittima — è esattamente quella che farei anch'io, al loro posto. Il problema è che è anche la domanda sbagliata. O meglio: è solo metà della domanda giusta.
Chiedere quanto costa un software su misura è molto simile a chiedere quanto costa una casa: dipende da dove la vuoi, quanto grande, con quali finiture, in che zona, con che vista. Lo spiega bene F.Technology in un'analisi che vale la lettura: la risposta secca non esiste, perché le variabili in gioco sono troppe.
Da qui, il punto di questo articolo. La domanda sul costo è legittima, ma incompleta. Garda Informatica, in una guida pensata proprio per le PMI, fa la stessa osservazione: la prima cosa che chiede un imprenditore è "quanto mi costa", ed è anche la prima domanda da cui non bisognerebbe partire.
Il pezzo che manca quasi sempre nei preventivi si chiama Total Cost of Ownership — il costo totale di possesso. Tradotto in cifra: il 60-70% del costo totale di un software emerge dopo il rilascio iniziale. Non prima. Dopo. Quel preventivo che avete sul tavolo è la punta dell'iceberg, non l'iceberg.
Questo articolo serve a darvi gli strumenti per capire davvero quanto costa un software su misura, senza sorprese a metà strada. Niente allarmismi, niente vendite aggressive. In Pizero abbiamo deciso da tempo che un cliente informato è semplicemente un cliente migliore — anche quando la consapevolezza lo porta a capire che, in fondo, di noi non ha bisogno.
Veniamo ai numeri, che è probabilmente il motivo per cui state ancora leggendo. Premessa importante: sono fasce indicative, non preventivi. Ogni progetto fa storia a sé, e chi vi dà una cifra precisa al primo incontro o ha capito tutto in dieci minuti (improbabile) o sta tirando a indovinare (più probabile).
Secondo un'analisi aggiornata sui prezzi reali per PMI nel 2026, queste sono le fasce per il mercato italiano:
Dove vanno questi soldi, in pratica? La ripartizione tipica del budget nel settore segue uno schema abbastanza riconoscibile:
WebPD lo dice in modo netto nella sua guida strategica: non esiste una risposta unica. Il costo dipende da cosa state digitalizzando, da quante integrazioni servono, dalle tecnologie scelte, dai tempi.
E qui c'è il punto che molti sottovalutano: queste cifre coprono solo la fase di sviluppo. Il TCO è un'altra storia. Comprate un'auto a 25.000€ — il prezzo di listino non include assicurazione, manutenzione, carburante, revisioni. Lo sapete e ne tenete conto. Nel software, stranamente, questa consapevolezza fatica ad arrivare. Prima ancora di entrare nei numeri, può valere la pena valutare anche la scelta tra software custom e piattaforme low-code: ha implicazioni dirette sul TCO a lungo termine, e non sempre quella che sembra ovvia è la più conveniente.
Veniamo all'elefante nella stanza. Il Total Cost of Ownership di un software custom comprende voci che, nei preventivi iniziali, non vedete quasi mai. Non sempre per cattiva fede del fornitore: spesso è una semplice questione di dinamica commerciale. Nessuno si presenta al primo incontro con un numero spaventoso — perdere un cliente è facilissimo, recuperarlo molto meno.
Ma siete qui per il quadro completo, quindi eccolo. I sei costi nascosti che vedremo uno per uno:
Da un'analisi strategica sui costi nascosti degli ERP emerge un dato chiaro: le voci di costo indiretto pesano soprattutto nella fase post-implementazione. Stima ragionevole? Il costo post-rilascio rappresenta il 150-200% del costo di sviluppo iniziale, su cinque anni. Tradotto: 25.000€ di sviluppo significano almeno 37.500-50.000€ di costi successivi. Numeri grossi, ma più trasparenti che sorprendenti — se li conoscete in anticipo.
Primo mito da sfatare: il software, al momento del rilascio, non è "finito". È probabilmente la differenza più grande tra il software e quasi qualsiasi altro prodotto. Un mobile lo compri e va bene per dieci anni. Un'applicazione, no. La manutenzione è strutturale, non opzionale.
La manutenzione si divide in tre tipi che vale la pena distinguere:
Il riferimento del settore è abbastanza stabile: la manutenzione annuale costa tipicamente il 15-25% del costo iniziale di sviluppo. Su un gestionale da 25.000€ parliamo di 3.750-6.250€ all'anno. Su cinque anni, sono tra i 18.750 e i 31.250€ — solo per tenere il software in salute, prima di aggiungerci una sola feature nuova.
C'è un dettaglio insidioso che Analytics Steps segnala bene nella sua analisi sui fattori di costo: la complessità delle funzionalità incide direttamente sui costi futuri di manutenzione. In pratica, un'architettura iniziale debole non si paga subito. Si paga dopo, e tutti gli anni. Per questo investire bene in fase di progettazione è uno dei modi più efficaci per ridurre il TCO.
Consiglio operativo: prima di firmare, mettete sul tavolo un contratto di manutenzione con SLA chiari. Cosa è incluso, cosa no, quali tempi di risposta, quali costi orari extra. È noioso, ma vi risparmia mesi di malumori dopo. Vale per qualsiasi progetto, e in particolare per l'automazione dei processi finanziari per PMI, dove la manutenzione tocca direttamente la compliance — e quindi il rischio aziendale.
Il debito tecnico è uno di quei concetti che ogni imprenditore dovrebbe conoscere, anche senza essere uno sviluppatore. L'analogia migliore l'ho sentita proprio in cantiere: costruire una casa risparmiando sulle fondamenta. All'inizio sembra tutto a posto. Dopo qualche anno, le crepe iniziano a comparire — e ripararle costa molto di più di quanto si era risparmiato.
Nel software è esattamente lo stesso meccanismo. Il debito tecnico è la somma di tutte le scorciatoie prese durante lo sviluppo che generano costi crescenti nel tempo. Si accumula quando:
La regola empirica è brutale: ogni ora "risparmiata" con una scorciatoia costa tra 5 e 10 ore di refactoring più avanti. Non è una regola precisa al decimale, ma rende l'idea — il moltiplicatore esiste, e fa male.
Come ci si accorge di averlo accumulato? Il software diventa più lento. I bug ricorrono. Una funzionalità che dovrebbe richiedere una settimana ne richiede tre. Se vi suona familiare, probabilmente avete un problema di debito tecnico. La buona notizia è che è gestibile. La cattiva è che ignorarlo lo fa peggiorare in modo non lineare.
La prevenzione parte dall'investimento iniziale. QArea lo formalizza nei numeri: testing e QA dovrebbero pesare il 20-25% del budget. È il classico costo che sembra alto e che invece previene costi esponenziali. Stessa logica vale per le fasi di design e prototyping: wireframe e prototipi non sono un orpello, sono il modo più economico di scoprire un errore prima che diventi codice.
In Pizero usiamo da tempo tecniche di agentic coding per produrre codice di qualità proprio per ridurre il debito tecnico in fase di scrittura. Non è una moda — è una scelta che fa la differenza sul TCO a tre-cinque anni. Conviene a voi clienti, e onestamente conviene anche a noi: passiamo meno tempo a rincorrere bug.
Questo è il costo nascosto che mi sta più a cuore. Non perché sia il più grande in valore assoluto, ma perché è quello che umilia di più le PMI sul lungo periodo. Il vendor lock-in è la dipendenza da un singolo fornitore che rende troppo costoso o tecnicamente impossibile cambiare. È una catena dorata, finché tutto va bene. È una prigione, quando smette di andare bene.
Le forme più comuni nel software custom sono quattro:
I numeri non sono incoraggianti: i costi di migrazione tra fornitori sono in genere il 50-80% del costo di sviluppo originale. Senza contare il downtime, i mesi di doppia gestione, la formazione del nuovo team. L'analisi di NTS Project sugli ERP lo dice senza giri di parole: la dipendenza dal fornitore è una delle voci più drammaticamente sottovalutate nei progetti software.
Una checklist veloce da fare prima di firmare il contratto:
Sei "sì" netti. Se anche solo uno è "no" — o "ne parliamo" — avete un'informazione importante.
È un tema che si lega anche alla conformità AI Act e GDPR per le PMI: la portabilità dei dati non è solo una buona pratica, è un obbligo normativo. Una motivazione in più per fare le cose pulite dall'inizio.
Avete il software pronto. Funziona. E adesso? Adesso comincia il pezzo che quasi nessun preventivo include: far sì che le persone lo usino davvero.
Non parlo del classico training di mezza giornata il lunedì del rilascio. Parlo di formazione iniziale per tutti gli utenti — e profili diversi hanno esigenze diverse: l'amministrativo e il commerciale non vogliono imparare le stesse cose. Parlo di formazione continua per nuove funzionalità e nuovi assunti. Parlo di materiali di supporto: guide, video tutorial, FAQ interne. Tutta roba che richiede tempo, e che qualcuno deve produrre.
Ma il costo più subdolo è quello del change management. Ogni nuovo software incontra resistenza — sempre. C'è il dipendente che "faceva prima con Excel", il manager che non ha tempo di imparare, il reparto che boicotta silenziosamente perché il vecchio sistema funzionava (per lui). Come nota Analytics Steps, complessità delle interfacce e numero di schermate non incidono solo sui costi di sviluppo, ma anche sui tempi e sui costi di adozione.
Poi c'è il costo-opportunità, che è la voce più difficile da quantificare ma forse la più importante. Durante i 3-12 mesi di sviluppo, i vostri processi attuali restano quelli che sono: inefficienti, manuali, costosi. Il ritorno arriva solo dopo, e nel frattempo il costo della situazione attuale continua a maturare. Garda Informatica la mette così: la domanda giusta non è "quanto costa", è "qual è il ROI nel mio contesto specifico". Sottoscrivo.
Consiglio: prevedete un budget formazione pari al 10-15% del costo di sviluppo. Sembra molto. È invece quello che fa la differenza tra un software che entra davvero nelle abitudini quotidiane e uno che dopo sei mesi viene aggirato con i vecchi Excel. Per un esempio concreto, come l'IA generativa sta cambiando i processi contabili nelle PMI è un caso interessante: l'adozione accelera proprio dove c'è formazione strutturata.
Dopo aver mappato le voci nascoste, passiamo al calcolo. Una formula semplice da applicare al vostro caso:
TCO 5 anni = Costo sviluppo + (Manutenzione annua × 5) + Formazione + Infrastruttura + Costi di integrazione + Buffer imprevisti (15-20%)
Esempio concreto. Un gestionale medio per una PMI, fascia indicata da Elia Zavatta:
Totale TCO a 5 anni: circa 69.000€.
Avete letto bene. Un gestionale "da 25.000€" ha un TCO realistico di 65.000-80.000€ su cinque anni. Conoscere questo numero in anticipo non serve a spaventarvi — serve a non farvi trovare impreparati al terzo anno, quando il fornitore vi propone un upgrade e voi non avete idea se rientra nel budget o no.
Detto questo: il TCO ha senso solo se confrontato con il valore generato. Se quel gestionale fa risparmiare due ore al giorno a tre persone, parliamo di 30.000-40.000€ all'anno di efficienza recuperata. Su cinque anni, l'investimento si ripaga abbondantemente. Il problema non è mai il costo in sé — è il rapporto tra costo e valore.
Per un confronto numerico tra software custom e low-code su orizzonte 5 anni, con TCO comparativi, trovate qui un nostro approfondimento dedicato. Le differenze sono significative — ma dipendono molto dal vostro caso. Non c'è una vittoria assoluta di una soluzione sull'altra: c'è la soluzione giusta per la vostra situazione.
Arriviamo alla parte pratica. Come si sceglie un fornitore in un mercato dove tutti promettono il miglior risultato al miglior prezzo? Si fanno domande. Possibilmente quelle giuste, prima di firmare.
Le 10 domande che farei a chiunque venisse a propormi un progetto:
Le risposte vi diranno molto. Non solo sul fornitore — anche su quanto è serio il vostro interlocutore. Chi tergiversa sulla #1 o sulla #10, in genere, vi sta dicendo qualcosa di importante.
Le red flag che ormai riconosco a colpo d'occhio:
In Pizero abbiamo fatto una scelta che ci è costata clienti: non vendiamo a tutti i costi. Aiutiamo a decidere con consapevolezza. Significa che a volte diciamo a chi viene da noi che, in realtà, non gli serve un software custom — un SaaS già pronto risolve a un decimo del costo. Sembra paradossale dirlo in un articolo che parla di software custom, ma è esattamente così che lavoriamo.
In concreto:
È una posizione che F.Technology condivide: la definizione precisa del perimetro è il primo passo per un preventivo realistico. Sottoscrivo.
I punti che mi sembrano i più importanti, senza ripetervi tutto:
Il software su misura resta un investimento eccellente per le PMI italiane — quando viene pianificato con cognizione di causa. Il punto non è spendere meno. È spendere bene. E per farlo, serve un partner che giochi a carte scoperte fin dal primo incontro.
Se volete una valutazione del TCO sul vostro progetto specifico, scriveteci. La prima analisi la facciamo sempre insieme, senza impegno e senza vendite aggressive — non è il nostro stile. Un cliente consapevole, per noi, vale dieci clienti convinti a forza.
