Sviluppo software su misura: quanto costa davvero, quanto dura e cosa deve dire il contratto

Hai tre preventivi per lo stesso software e vanno da diciottomila a settantamila euro. Nessuno dei tre è sbagliato, ed è proprio questo il problema: stanno rispondendo a tre domande diverse, e la domanda avresti dovuto scriverla tu.

In questo articolo trovi il conto vero di uno sviluppo software su misura in Italia. Le tariffe che si pagano davvero e i tre scaglioni di progetto con i numeri. Perché le stime saltano sempre nella stessa direzione e dove va a finire il tempo che nel piano non c'era. Il documento di due pagine da scrivere prima di chiedere un'offerta, che è la cosa che fa risparmiare di più in assoluto. Le sette clausole di contratto che decidono se fra tre anni quel software è tuo oppure del fornitore. E i sette segnali che un progetto sta andando a sbattere mentre nelle riunioni tutti continuano a dire che va bene.

Faccio software da ventisei anni. Ho scritto su misura per banche, industria, studi professionali e piccole aziende di provincia, ho costruito un prodotto mio e l'ho venduto, e ho passato una parte non piccola di questo tempo a rimettere in piedi progetti che qualcun altro aveva lasciato a metà. I progetti falliti che ho visto non sono quasi mai falliti per motivi tecnici.

La premessa da cui discende tutto il resto è questa: quando compri software su misura non stai comprando righe di codice, stai comprando le decisioni che qualcuno prenderà al posto tuo per i prossimi mesi. Il codice è la parte facile e oggi è anche la parte che costa meno. Le decisioni, invece, sono tue: se non le prendi, le prende il fornitore, e le prenderà nel modo più comodo per lui, che non è quasi mai il modo più utile per te.

Quando lo sviluppo software su misura conviene davvero e quando è solo un capriccio caro

C'è una domanda che viene prima del preventivo, prima della tecnologia e prima ancora della scelta del fornitore, e quasi nessuno se la pone per iscritto: che cosa succede se questo software non lo faccio?

Se la risposta è "continuiamo come adesso e va bene lo stesso", il progetto non ha una ragione economica e prima o poi si fermerà, non importa quanto sia stato scritto bene il contratto. Se invece la risposta contiene un numero, cioè ore di lavoro buttate, ordini persi, penali, clienti che se ne vanno o un margine che si assottiglia ogni mese, allora c'è un progetto e c'è anche un budget, perché il budget si ricava da quel numero.

Faccio un esempio che ho visto in una forma o nell'altra decine di volte. Un'azienda di quaranta persone in cui tre impiegate passano ogni mattina due ore a ricopiare dati da un sistema all'altro. Sono sei ore al giorno, circa milletrecento ore all'anno, che al costo pieno aziendale valgono qualcosa fra i trentacinquemila e i quarantacinquemila euro. Un software che elimina quel travaso, e che costa venticinquemila euro, si ripaga in meno di un anno. Non serve altra analisi: quel numero è già la giustificazione, il budget e il criterio con cui si giudicherà il risultato.

Le tre condizioni che devono valere insieme

Il software su misura ha senso quando ricorrono tutte e tre queste cose, non una o due.

La prima: quello che fai è diverso da come lo fanno gli altri, e quella differenza è il tuo margine. Se il modo in cui prezzi, in cui pianifichi la produzione o in cui gestisci le eccezioni sui clienti è una parte di come guadagni, un prodotto in pacchetto ti costringerà a rinunciarci, perché un pacchetto è costruito sulla media di mille aziende e tu sei fuori media proprio nel punto in cui guadagni. Se invece la tua differenza è "abbiamo sempre fatto così", allora non è un margine, è un'abitudine, e le abitudini si cambiano a costo molto più basso di quanto costi un software.

La seconda: il processo che vuoi automatizzare esiste già e funziona. Automatizzare un processo confuso produce un software confuso, con l'aggravante che dopo la confusione è scritta nel codice e per cambiarla serve un preventivo. Se il processo non esiste ancora, la cosa giusta da fare è farlo girare per qualche mese con un foglio di calcolo e la buona volontà: costa quasi zero, e alla fine avrai in mano le regole vere invece di quelle immaginate.

La terza: c'è una persona in azienda che può dire di sì e di no. Non un comitato, non "ne parliamo in riunione": una persona che conosce il processo, ha l'autorità per decidere e ha davvero il tempo. Un progetto su misura richiede fra le due e le sei ore alla settimana di questa persona per tutta la durata. È la risorsa più scarsa dell'intero progetto ed è quella che nessun preventivo elenca. Se quella persona non c'è o non ha quelle ore, il progetto va rimandato: non è una questione di soldi, è che senza decisioni tempestive il fornitore si ferma o, peggio, decide da solo.

I quattro casi in cui non farlo, e cosa fare invece

Esiste un prodotto che fa il novanta per cento di quello che ti serve. Compralo, e per il dieci per cento che manca valuta se cambiare il processo o se serve solo un pezzo su misura attaccato al prodotto. Il conto completo di questa decisione, con la soglia oltre la quale il pacchetto smette di convenire, l'ho fatto in gestionale aziendale, quando il pacchetto basta e quando ti serve su misura.

Il vero problema è un'integrazione, non un'applicazione. Succede spesso: si chiede un software nuovo perché due sistemi che ci sono già non si parlano. Costruire il terzo sistema non risolve niente e aggiunge un posto in cui i dati possono divergere. In quel caso il lavoro da fare è un altro, e l'ho descritto in integrazione fra gestionale ed e-commerce.

Il software che hai è vecchio ma fa esattamente quello che serve. Rifarlo da zero per modernizzarlo è quasi sempre la strada più cara e più rischiosa che esista, perché insieme al codice vecchio butti via quindici anni di casi particolari che nessuno ha mai scritto da nessuna parte. Il percorso incrementale costa meno e rompe meno cose: l'ho raccontato in modernizzazione del software legacy, e nel caso specifico delle applicazioni .NET in migrazione da .NET Framework a .NET 10.

Vuoi il software per convincere qualcuno. Un investitore, un cliente, un consiglio di amministrazione. Per quello serve un prototipo, che costa una frazione e si butta via senza rimpianti. Un prototipo che diventa il prodotto per inerzia è una delle cause di fallimento più frequenti e meno raccontate: nasce senza pensare ai dati, senza pensare agli errori e senza pensare a chi lo userà davvero, e quelle tre mancanze si pagano tutte insieme, sempre nel momento peggiore.

Quanto costa un software su misura in Italia nel 2026

Parto dal mattone, perché tutto il resto è aritmetica sopra questo numero. Il costo di una giornata di lavoro di uno sviluppatore, in Italia, oggi.

Le tariffe vere, per tipo di fornitore

Un freelance senior italiano sta fra i quattrocento e i seicento euro al giorno. Sotto i trecento, per un profilo che si dichiara senior, c'è quasi sempre qualcosa che non torna: o non è senior, o è disperato, o sta lavorando su altri tre progetti contemporaneamente e tu sei quello che aspetta.

Una software house italiana sta fra i quattrocento e gli ottocento euro al giorno a persona, ed è la forbice che si vede nella maggior parte delle offerte serie. In quella cifra ci sono cose che il freelance non ti dà: qualcuno che sostituisce chi si ammala, un secondo paio di occhi sul codice, una struttura che sopravvive alle ferie di agosto.

Una società di consulenza grande sta fra gli ottocento e i milleduecento euro al giorno, e quasi sempre con un rapporto fra persone esperte e persone giovani che vale la pena chiedere prima di firmare. La domanda giusta non è quanto costa la giornata, è quante di quelle giornate saranno di una persona che ha già fatto questa cosa altre volte.

Un fornitore estero a basso costo sta fra i centocinquanta e i trecento euro al giorno. È una scelta legittima e in alcuni casi funziona benissimo, ma il conto va fatto intero: aggiungi il tempo tuo per specificare tutto in modo molto più preciso, il fuso orario, la lingua, e soprattutto il fatto che il divario di produttività fra chi capisce il tuo dominio e chi esegue una specifica è enorme. Sul rapporto fra spesa e risultato, un fornitore a duecento euro al giorno che ha bisogno del triplo delle giornate costa di più di uno a seicento, e ti costa anche mesi.

Il numero di riferimento che uso per fare i conti a mente in una prima telefonata è cinquecento euro al giorno, che corrisponde a circa duemilacinquecento euro a settimana e a circa diecimila euro al mese per una persona a tempo pieno. Da lì in avanti la conversazione diventa semplice, perché ogni funzionalità si può tradurre in giorni e ogni giorno in euro.

I tre scaglioni di progetto, con i numeri

Piccolo: da ottomila a venticinquemila euro, sei-dodici settimane. Un'applicazione che risolve un problema solo e lo risolve bene. Un portale dove i clienti caricano documenti e vedono lo stato della loro pratica. Uno strumento che prende quattro fogli di calcolo e li trasforma in un archivio con i permessi giusti. Un'automazione che elimina un travaso manuale. Di solito una decina di schermate, un archivio dati, uno o due collegamenti verso sistemi esistenti, da dieci a cinquanta persone che lo useranno.

Medio: da venticinquemila a ottantamila euro, tre-otto mesi. Un'applicazione che copre un processo intero e che entra nel giro quotidiano dell'azienda. Un gestionale di reparto, un configuratore di prodotto, un sistema di pianificazione della produzione, un portale per la rete di vendita. Qui compaiono i ruoli e i permessi, le integrazioni vere con i sistemi che ci sono già, il caricamento dei dati storici e, per la prima volta, il fatto che se il software si ferma qualcuno smette di lavorare.

Grande: da ottantamila euro in su, oltre gli otto mesi. Un sistema su cui gira l'azienda, o un prodotto che venderai a tuoi clienti. Non è più un progetto, è un pezzo di azienda che nasce, e va trattato come tale: ha un budget annuale, ha qualcuno che ne risponde e ha una vita che si misura in anni. Se ti trovi in questo scaglione al primo progetto, il consiglio è dividerlo, e ci torno più avanti perché è il singolo consiglio che fa risparmiare di più.

Perché tre preventivi per la stessa cosa differiscono di quattro volte

Non è disonestà, quasi mai. È che i tre fornitori hanno letto la stessa richiesta e hanno immaginato tre software diversi, e quello che li separa sono cinque voci che nella richiesta non c'erano.

Quante eccezioni. "Gestione ordini" può voler dire un elenco con quattro stati, oppure un flusso con approvazioni, sconti a scaglioni, blocchi per fido superato e regole diverse per tre canali di vendita. La differenza fra i due è di un fattore cinque, e sta tutta in una riga della richiesta che non è stata scritta.

Quanti dati vecchi. Nessuno ti fa pagare "il caricamento dei dati" nel preventivo, e nessuno immagina che quei dati siano in tre fogli di calcolo con i nomi dei clienti scritti in cinque modi diversi. La bonifica dei dati storici, su un progetto medio, vale spesso fra il dieci e il venti per cento del totale, e nel novanta per cento dei preventivi vale zero.

Con quanti sistemi deve parlare. Ogni integrazione con un sistema esistente vale da tre a quindici giornate a seconda di quanto quel sistema è disposto a farsi interrogare. Un gestionale moderno con un'interfaccia documentata sta in basso, un gestionale di vent'anni fa da cui si estraggono i dati leggendo direttamente le sue tabelle sta in alto, e ci sono casi in cui la parte più costosa è capire che cosa significano quelle tabelle.

Chi lo userà. Un software usato da cinque persone in ufficio e un software usato da trecento agenti sul telefono hanno lo stesso elenco di funzioni e un costo diverso del doppio, perché nel secondo caso la stessa funzione va progettata per chi ha fretta, ha una mano occupata e non ha nessuno a cui chiedere.

Quanto è grave se si ferma. Un software che se si ferma fa perdere mezz'ora di lavoro e un software che se si ferma blocca le spedizioni non sono lo stesso prodotto. Il secondo richiede copie di sicurezza verificate, sorveglianza attiva, un piano per il ripristino e qualcuno reperibile: da solo può valere il venti-trenta per cento in più.

Quando ricevi tre preventivi molto diversi, la cosa utile non è scegliere il più basso e nemmeno il più alto. È prendere le cinque voci qui sopra e chiedere a tutti e tre che cosa hanno assunto su ognuna. Le risposte ti diranno chi ha capito il problema, e quasi sempre chi ha capito il problema non è il più economico dei tre né il più caro.

Il conto che nessuno ti fa: cinque anni, non cinque mesi

Il numero in fondo al preventivo è il costo per arrivare al primo giorno di funzionamento. Non è il costo del software: è il costo del suo primo giorno. Il costo vero si vede sui cinque anni, e ha quattro voci, di cui tre di solito non compaiono da nessuna parte.

La costruzione

È l'unica voce nel preventivo. Chiamiamola cento, così il resto si legge in proporzione.

L'esercizio

Il software deve girare da qualche parte, e quel posto ha un costo mensile. Per un'applicazione gestionale interna con qualche decina di utenti, oggi si sta fra i cinquanta e i quattrocento euro al mese di infrastruttura, purché sia dimensionata con criterio: sugli errori tipici, quelli che trasformano una bolletta da ottanta euro in una da ottocento, ho scritto come risparmiare su Azure senza perdere affidabilità. Aggiungi i servizi di terze parti che userai: la firma digitale, l'invio delle email, i pagamenti, le mappe. Ognuno ha un canone piccolo e sono cinque, e la somma non è più piccola.

La manutenzione ordinaria

Questa è la voce che manca sempre e che poi arriva. Un software vivo costa ogni anno fra il quindici e il venticinque per cento di quanto è costato costruirlo, e non è una scelta: è una condizione per continuare a usarlo.

Non è manutenzione nel senso di aggiungere funzioni. È il browser che si aggiorna e cambia un comportamento, è una libreria con un problema di sicurezza da sostituire, è una legge che cambia un tracciato, è il fornitore di un servizio che modifica la sua interfaccia con sei mesi di preavviso. Su un progetto da quarantamila euro sono fra i seimila e i diecimila euro all'anno che vanno messi a bilancio prima di firmare, non scoperti al secondo anno quando qualcuno chiede perché il fornitore manda una fattura per un software "già pagato".

L'evoluzione

Il software funziona, le persone lo usano, e da quel momento chiedono. È un ottimo segno: significa che è entrato nel lavoro vero. Su un progetto medio, un budget ragionevole di evoluzione è fra il venti e il quaranta per cento del costo iniziale ogni anno per i primi due anni, e poi cala.

Il modo peggiore di gestirla è a preventivi singoli, perché ogni richiesta diventa una trattativa e la gente smette di chiedere anche quando servirebbe. Il modo migliore che ho visto è comprare un monte di giornate all'anno, decidere le priorità ogni mese e usarle. Costa uguale, è prevedibile e cambia completamente il rapporto con il fornitore.

Il conto messo in fila

Un progetto da quarantamila euro di costruzione, sui cinque anni, sta realisticamente fra i novantamila e i centoventimila euro. Non è un rincaro nascosto: è il costo di avere un software vivo per cinque anni invece che una consegna. La differenza fra chi lo sa prima e chi lo scopre dopo non è economica, è di rapporto: il primo ha comprato uno strumento, il secondo si sente truffato dal secondo anno in avanti.

La domanda da fare a ogni fornitore, per iscritto, prima di firmare, è una sola: quanto costa tenerlo vivo ogni anno, e che cosa comprende esattamente quella cifra? Chi risponde con un numero e un elenco ha già fatto questo lavoro altre volte. Chi risponde "vediamo strada facendo" ti sta dicendo che il conto lo farà quando non potrai più cambiare fornitore.

Quanto dura davvero e perché le stime saltano sempre nella stessa direzione

Le stime dei progetti software sbagliano quasi sempre per difetto, e sbagliano di una quantità sorprendentemente costante: fra una volta e mezza e due volte. È un fatto talmente regolare che vale la pena trattarlo come una legge di natura invece che come una colpa.

Da dove viene lo scarto

Uno sviluppatore che stima "tre giorni" sta stimando onestamente il tempo per scrivere quella cosa. Non sta stimando il tempo per capire che il campo Data in archivio contiene anche stringhe vuote, per aspettare che qualcuno risponda su come si comporta il sistema quando il cliente è bloccato, per rifare la schermata dopo che l'ha vista chi la userà, per scrivere le prove automatiche, per rimettere le mani su una funzione fatta due settimane fa perché la nuova la contraddice.

Su un progetto vero, la scrittura di codice nuovo occupa fra il trenta e il quaranta per cento del tempo. Il resto sono capire, aspettare, provare, correggere e coordinarsi. Chi stima solo la prima fetta ottiene un numero che sarà sbagliato di due volte, sempre.

Da qui una regola pratica che consiglio a chi compra, non a chi vende: prendi la stima che ti hanno dato, aggiungi il settanta per cento, e chiediti se il progetto ha ancora senso a quella cifra e a quella data. Se ce l'ha, procedi con serenità. Se non ce l'ha, il problema non è la stima: è che stai comprando qualcosa che era già al limite, e il limite lo supererà.

Le quattro cose che non erano nel preventivo

I dati vecchi. Sono sempre peggio di come li descrive chi li possiede. Ci sono duplicati, campi usati per contenere una cosa diversa da quella che dice il nome, date impossibili, clienti scritti in cinque modi. Non è colpa di nessuno: sono quindici anni di persone diverse che hanno fatto funzionare le cose. Il modo per non prendere questa botta è chiedere, come primissima attività del progetto, un rapporto in sola lettura sui dati esistenti. Due o tre giorni di lavoro, non tocca niente e non può rompere niente, e restituisce l'elenco delle sorprese prima che diventino ritardi.

Le persone che lo useranno. Quello che il capo descrive è il processo come dovrebbe essere. Quello che fanno le persone è il processo come è, con le scorciatoie che hanno inventato per farlo funzionare. Le due cose divergono sempre, e la divergenza salta fuori alla prima dimostrazione, cioè tardi. Mezza giornata passata a guardare lavorare tre persone, prima di scrivere una riga, sposta un progetto più di due settimane di riunioni.

Le integrazioni. Ogni sistema esterno è una promessa fatta da qualcun altro. La documentazione è vecchia, l'ambiente di prova non c'è, la password arriva in tre settimane, e il comportamento vero non coincide con quello scritto. Non è pessimismo: è la norma. Le integrazioni vanno provate all'inizio del progetto e non alla fine, anche solo con una chiamata banale, perché è l'unico modo di scoprire presto una cosa che scoperta tardi ferma tutto.

I permessi e le persone che decidono. Accessi ai sistemi, autorizzazioni, il referente in ferie, il consulente esterno che deve dare l'ok. Sono le settimane più stupide di un progetto e sono anche quelle che nessuno mette a piano. Si prevengono in un modo solo: elencare all'inizio tutto quello che serve da terzi, con un nome e una data accanto.

Come si compra il tempo invece di comprare il ritardo

Il consiglio più utile che posso dare a chi affronta il primo progetto è di non comprare tutto insieme. Un progetto da otto mesi ha una caratteristica velenosa: per otto mesi non sai se sta andando bene, e quando lo scopri hai già speso tutto.

La forma che funziona è diversa. Si sceglie la fetta che, da sola, vale già qualcosa per l'azienda, e si compra quella. Sei-otto settimane, un pezzo che va in mano alle persone vere e che produce un risultato misurabile. Poi si decide se continuare, e si decide con dei fatti invece che con delle speranze: hai visto lavorare il fornitore, hai visto la reazione degli utenti, hai un numero.

Questo costa forse il dieci per cento in più in totale, perché qualche cosa si rifà. In cambio, il rischio massimo passa da tutto il budget al costo di una fetta. È l'assicurazione meno cara che esista in questo mestiere, e quasi nessuno la compra.

Il documento di due pagine da scrivere prima di chiedere un preventivo

Qui c'è un equivoco che costa moltissimo. Molti pensano che l'alternativa a "spiego a voce cosa mi serve" sia un capitolato di ottanta pagine. Non è così, e il capitolato di ottanta pagine è spesso peggio del racconto a voce: è lungo, nessuno lo legge fino in fondo, descrive nel dettaglio le cose facili e resta vago proprio sulle cose che decidono il prezzo.

Quello che serve sono due pagine, scritte da te, in italiano normale. Sono le due pagine che fanno risparmiare di più in tutto il progetto, e si scrivono in un pomeriggio.

Le otto voci

1. Il problema, in cinque righe, con un numero dentro. Non la soluzione: il problema. "Tre persone passano due ore al giorno a ricopiare gli ordini dal portale al gestionale, e una volta a settimana un ordine si perde." Un fornitore serio, leggendo questo, può proporti anche una soluzione che non avevi immaginato, e a volte è più economica.

2. Chi lo userà, quanti sono, da dove. Cinque impiegate al computer in ufficio, oppure ottanta tecnici sul telefono in cantiere senza campo. Cambia tutto ed è una riga.

3. Le tre cose che devono funzionare il primo giorno. Solo tre. Questo esercizio è fastidioso e proprio per questo è utile: obbliga a distinguere l'essenziale dal desiderabile, e ti dà il criterio per giudicare la prima consegna.

4. Le cose che potete aspettare. Elencarle serve a due cose: il fornitore le tiene presenti nel progettare, e tu non le paghi adesso.

5. I sistemi con cui deve parlare, con nome e versione. Non "il nostro gestionale": il nome, la versione, e se possibile chi lo mantiene. È l'informazione che sposta di più il prezzo e nella maggior parte delle richieste non c'è.

6. I dati che esistono già e dove stanno. Quante righe, in che forma, chi li ha messi lì. Anche se la risposta è "quattro fogli di calcolo tenuti da Anna", scriverla vale più di dieci righe di descrizione funzionale.

7. Le vostre eccezioni. Le regole che applicate voi e che un'azienda qualunque del vostro settore non applicherebbe. Sono la parte più preziosa del documento perché sono la ragione per cui state comprando su misura, e sono quasi sempre quelle che nessuno racconta perché a chi ci lavora sembrano ovvie.

8. Quanto siete disposti a spendere e per quando vi serve. Molti non lo scrivono per paura che il preventivo salga fino alla cifra dichiarata. Succede il contrario: un fornitore che conosce il budget può dirti che cosa ci sta dentro, e un fornitore che non lo conosce ti proporrà il progetto che immagina lui, che quasi sempre non è quello che puoi permetterti. Se una cifra non si può fare, è meglio saperlo la prima settimana.

Come usarlo

Manda queste due pagine a tre fornitori diversi, non a uno solo, e leggi non tanto i prezzi quanto le domande che ti fanno. Un fornitore che ti fa un prezzo senza farti domande sta tirando a indovinare, e la differenza fra la sua ipotesi e la realtà la pagherai tu, o in aumenti o in un software che non fa quello che serve.

Le domande buone si riconoscono: riguardano le eccezioni, i dati vecchi, che cosa succede quando le cose vanno storte e chi in azienda deciderà. Le domande deboli riguardano il colore dei bottoni e la tecnologia preferita.

Come si sceglie il fornitore: dieci domande e cinque bandiere rosse

Il criterio che uso quando qualcuno mi chiede di aiutarlo a scegliere è semplice: non cerco il fornitore più bravo tecnicamente, cerco quello che ha già fatto tre volte una cosa simile alla tua e che risponde alle domande scomode senza girarci intorno.

Le dieci domande

1. Mi fate parlare con due clienti per cui avete fatto una cosa simile? Non le referenze scritte sul sito: due numeri di telefono. Chi ha lavorato bene ne ha, e li dà volentieri.

2. Chi lavorerà sul mio progetto, con nome e cognome, e su quali altri progetti sarà nello stesso periodo? È la domanda che smonta la differenza fra chi ti ha venduto e chi ti farà il lavoro.

3. Che cosa succede se la persona che segue il progetto se ne va? La risposta giusta descrive una pratica, non una rassicurazione: il codice è scritto in modo che lo capisca un altro, c'è una documentazione minima, c'è una seconda persona che sa dove mettere le mani.

4. Ogni quanto vedrò qualcosa che funziona? La risposta accettabile si misura in settimane, non in mesi, e "qualcosa che funziona" significa che ci posso cliccare io, non una presentazione.

5. Dove starà il codice sorgente? La risposta giusta è: in un archivio intestato a te, a cui tu hai accesso da subito, con dentro tutto quello che serve a far ripartire il progetto altrove. Ci torno fra poco perché è la clausola più importante di tutte.

6. Come vengono gestite le richieste che non erano previste? Ce ne saranno, sempre. Deve esistere un modo già concordato per valutarle e per decidere se entrano al posto di qualcos'altro o in aggiunta, e questo modo va scritto prima, quando il rapporto è ancora sereno.

7. Che cosa non farete? Un fornitore esperto ha una risposta pronta a questa domanda, e di solito è una risposta interessante. Chi dice che sa fare tutto sta dicendo che non ha ancora incontrato i suoi limiti, il che è più preoccupante che rassicurante.

8. Quanto costa tenerlo vivo il secondo anno? Numero ed elenco, come sopra.

9. Come faccio a sapere che sta andando bene mentre lo fate? Devono esistere due o tre indicatori concordati, guardabili da te senza chiedere permesso.

10. Se ci lasciamo fra un anno, che cosa mi resta in mano? È la domanda più scomoda ed è quella che separa i fornitori dai proprietari del tuo software. La risposta giusta è un elenco di cose concrete e una procedura per ottenerle.

Le cinque bandiere rosse

Il preventivo arriva senza domande. Già detto, ma è la più frequente e la più costosa.

Il prezzo è molto sotto gli altri due. Nel software non esiste lo sconto sulla materia prima: la materia prima è tempo di persone. Un prezzo che è metà degli altri significa metà del tempo, e metà del tempo significa che qualcosa non sarà fatto. Quasi sempre è la parte che non si vede: le prove, la gestione degli errori, la sicurezza, la sistemazione dei dati.

La tecnologia viene prima del problema. Se nella prima riunione ti spiegano perché usano un certo strumento e non ti hanno ancora chiesto come lavori, stai comprando il loro entusiasmo, non la tua soluzione.

Il codice resta da loro "per comodità". Non è una comodità, è una posizione negoziale che si fa sentire alla prima divergenza di opinioni.

Non ti sanno dire chi userà il software. Se alla domanda "chi lo userà tutti i giorni" rispondono con i ruoli aziendali invece che con le persone e con quello che fanno, non hanno ancora capito il problema, e progetteranno per il committente invece che per l'utente. È l'errore che produce i software che nessuno usa.

Il contratto: le sette clausole che decidono se il software è tuo

Questa è la parte che quasi nessuno legge con attenzione, e che decide da sola metà del valore di quello che stai comprando. Non sono clausole ostili al fornitore: un fornitore serio le accetta tutte senza discutere, perché sono il modo normale di lavorare. La resistenza su una di queste, di per sé, è già un'informazione.

1. La proprietà del codice, scritta in modo esplicito

Il contratto deve dire che i diritti di utilizzazione economica del software realizzato su commessa sono tuoi, in via esclusiva, senza limiti di tempo e di territorio, e che ti vengono trasferiti man mano che il lavoro procede. La formulazione da evitare è "il cliente ottiene una licenza d'uso": è una cosa diversa e nel tempo pesa molto.

Va gestita anche la parte che il fornitore riusa da un cliente all'altro, e va gestita adesso perché esiste in quasi tutte le software house. La forma equilibrata è: quello che il fornitore aveva già prima resta suo e tu ricevi il diritto perpetuo e irrevocabile di usarlo dentro il tuo software, mentre tutto quello che è stato scritto per te è tuo. Quello che non deve succedere è scoprire fra due anni che una parte essenziale del sistema è un componente del fornitore che non puoi far modificare a nessun altro.

2. Il codice sorgente in casa tua, dal primo giorno

Non alla consegna: dal primo giorno. L'archivio del codice va intestato alla tua azienda, con un tuo indirizzo email come proprietario, e il fornitore vi accede come collaboratore. Costa zero, cambia tutto.

Dentro non deve esserci solo il codice, ma anche le istruzioni per farlo partire da una macchina vuota, la struttura dell'archivio dati e le procedure di rilascio. La prova che questa clausola è rispettata sul serio è una sola, e vale la pena pretenderla a metà progetto: una persona esterna, con quello che c'è nell'archivio e nient'altro, riesce a far girare il software. Se non ci riesce, quello che hai non è il tuo software: è la promessa che il tuo fornitore te lo farà girare.

3. Le dipendenze e le licenze, dichiarate

Ogni software moderno è fatto anche di componenti di terzi. Il contratto deve prevedere un elenco aggiornato di questi componenti con la relativa licenza, e l'impegno che nessuno di essi imponga obblighi incompatibili con il tuo uso. È una richiesta banale da soddisfare, e il giorno che compri o vendi un'azienda diventa una delle prime cose che qualcuno ti chiederà.

4. L'infrastruttura intestata a te

Il dominio, l'abbonamento cloud, i servizi di terze parti: intestati alla tua azienda, pagati da te, con il fornitore che vi accede con un suo utente. È l'errore più frequente e il più fastidioso da correggere dopo: quando l'abbonamento è del fornitore, cambiare fornitore significa migrare tutto sotto ricatto di tempo, e il costo di quella migrazione è sempre superiore al risparmio di aver lasciato fare a lui.

5. I dati sono tuoi ed escono in un formato leggibile

Deve esistere, e deve essere provata prima della fine del progetto, una procedura che estrae tutti i tuoi dati in un formato aperto e documentato. Non "possiamo fare un'estrazione se serve": una procedura che qualcuno ha lanciato almeno una volta e di cui hai visto il risultato.

6. Che cosa vuol dire "funziona", e chi lo dice

La consegna va legata a criteri verificabili concordati prima, non a un'impressione. Non serve un documento lunghissimo: bastano dieci-quindici frasi del tipo "un operatore inserisce un ordine con tre righe e uno sconto e il gestionale lo riceve entro cinque minuti con il totale corretto". Sono frasi che chiunque può verificare, e tolgono di mezzo la discussione più logorante che ci sia, quella su che cosa fosse compreso.

7. L'uscita, descritta quando siete ancora d'accordo

Il contratto deve dire che cosa succede se il rapporto finisce: quanti giorni di affiancamento sono compresi, a che prezzo, con quale preavviso, e quali materiali vengono consegnati. Si scrive in dieci righe e si scrive all'inizio, perché alla fine, quando serve, nessuno ha più voglia di essere ragionevole.

Aggiungo una cosa che non è una clausola ma che vale quanto le sette. Se il software su cui gira la tua azienda dipende da una sola persona, il rischio più grande non è tecnico né contrattuale: è che quella persona cambi vita. Il modo di ridurlo è avere il codice, avere l'infrastruttura, avere i dati e avere un secondo fornitore che ogni tanto guarda le cose. Sul come ci si organizza quando il software cresce oltre una persona sola, ho scritto quanto costa realmente un team di sviluppo .NET.

Come si paga: a corpo, a tempo, a sprint

Le forme sono tre e non sono equivalenti. La scelta della forma sposta il rischio da una parte all'altra del tavolo, e conviene sapere in che direzione lo sta spostando.

A corpo: prezzo fisso per un risultato definito

Sembra la più sicura per chi compra e in parte lo è: sai quanto spendi. Il prezzo però contiene un margine di sicurezza che il fornitore aggiunge per coprirsi dall'incertezza, e più la richiesta è vaga più quel margine è alto. Se alla fine il progetto era semplice, quel margine l'hai pagato lo stesso.

C'è un effetto collaterale peggiore. A prezzo fisso, ogni cambiamento diventa una trattativa, e siccome i cambiamenti in un progetto software sono inevitabili, il rapporto scivola dalla collaborazione alla contabilità. Nei casi peggiori il fornitore inizia a difendere il perimetro invece di risolvere il problema, e tu smetti di segnalare le cose per non aprire l'ennesima discussione.

Va bene quando il perimetro è davvero chiuso e piccolo: una fase iniziale, un'integrazione singola, un lavoro che si può descrivere in una pagina senza sentirsi in imbarazzo.

A tempo: si paga quello che si consuma

È la forma più onesta rispetto a come funziona davvero il lavoro, ed è quella che tutti temono perché sembra un assegno in bianco. Non lo è, se si mettono due paletti: un tetto massimo oltre il quale ci si ferma e si parla, e una rendicontazione che si legge in due minuti, con che cosa è stato fatto e quanto è costato.

Va bene quando il problema è ancora da capire, quando c'è di mezzo un sistema vecchio che riserverà sorprese, o quando il progetto è lungo e cambierà per forza strada.

A sprint: si compra un periodo, non un elenco

È la forma che uso più spesso e che consiglio quasi sempre. Si compra un blocco di due settimane a un prezzo fisso, all'inizio del blocco si decide insieme che cosa ci sta dentro, alla fine si vede qualcosa che funziona e si decide se comprare il blocco successivo.

Il vantaggio è che il rischio massimo, in qualunque momento, è un blocco. Non ci sono trattative sui cambiamenti, perché ogni due settimane si ridecide. E c'è un beneficio meno ovvio: obbliga entrambe le parti a pensare in termini di priorità invece che di elenco completo, che è il modo in cui le cose vengono davvero fatte.

Lo svantaggio è che richiede più coinvolgimento da parte tua: quelle due-sei ore alla settimana di cui parlavo all'inizio diventano un impegno reale, non un'intenzione. Chi non è disposto a metterle è meglio che scelga il prezzo fisso, e metta in conto il margine di sicurezza.

La forma mista, che è quella che funziona

Nella pratica il modo che dà i risultati migliori è misto. Una prima fase breve a prezzo fisso, due o tre settimane, il cui prodotto non è codice ma chiarezza: il rapporto sui dati esistenti, le integrazioni provate davvero, il perimetro della prima consegna e una stima che a quel punto vale qualcosa. Costa fra i tremila e gli ottomila euro su un progetto medio ed è la spesa con il rendimento più alto di tutto il progetto, perché elimina lo scarto di stima proprio dove è più grande.

Poi il resto a blocchi. E, dopo la messa in produzione, un monte di giornate annuale per manutenzione ed evoluzione, con priorità decise ogni mese.

I sette segnali che il progetto sta per fallire

I progetti non falliscono all'improvviso. Danno segnali per settimane, e sono sempre gli stessi sette. Il valore di conoscerli è che ognuno ha una mossa di risposta che costa poco se fatta subito e moltissimo se fatta al mese sesto.

1. Sono passate tre settimane e non hai ancora cliccato su niente. Ti hanno mostrato disegni, presentazioni, magari un'analisi. Nessun software che funziona. La mossa: chiedi qualcosa di funzionante entro dieci giorni, anche brutto, anche parziale. Se la risposta è che non è possibile perché prima va completata l'architettura, il progetto sta prendendo la strada in cui i problemi si scoprono tutti insieme alla fine.

2. Le riunioni sono diventate rassicurazioni. Quando lo stato passa da "questa settimana abbiamo chiuso queste tre cose e ne è saltata fuori una nuova" a "stiamo procedendo bene", qualcosa si è rotto. La mossa: chiedi l'elenco delle cose chiuse e di quelle aperte, per iscritto, ogni settimana. È una richiesta normale e la reazione ti dirà molto.

3. Le stesse cose vengono "quasi finite" più volte. Una funzione dichiarata pronta a marzo torna aperta ad aprile e poi a maggio. Significa quasi sempre che non esistono criteri per dire quando una cosa è finita. La mossa: le quindici frasi verificabili di cui parlavo prima, scritte anche a metà progetto. Non è mai tardi per introdurle.

4. Nessuno degli utenti veri l'ha ancora visto. Il software viene mostrato solo a chi lo ha commissionato. La mossa: metti il software in mano a due persone che lo useranno, per un'ora, e stai zitto a guardare. È l'ora più istruttiva dell'intero progetto e succede sempre troppo tardi.

5. Il fornitore ha smesso di dire di no. All'inizio spiegava perché una richiesta era costosa o sbagliata. Adesso dice sì a tutto. Non è servizio: è resa. Chi dice sì a tutto ha smesso di progettare e sta accumulando debito che pagherai in ritardi e in cose che si rompono a vicenda.

6. La lista delle cose da fare cresce più in fretta di quanto si accorci. Va misurato, non percepito: due numeri alla settimana, aperte e chiuse. Se per tre settimane di fila le aperte crescono, il progetto non sta convergendo, e continuare a spingere non serve. La mossa è tagliare il perimetro, non aggiungere persone.

7. Nessuno sa dire quanto manca. Non "non lo so con precisione", che è onesto: proprio l'impossibilità di indicare un ordine di grandezza. Significa che non c'è più una mappa. La mossa è fermarsi una settimana e rifare l'elenco di quello che manca davvero. Sembra tempo perso e non lo è mai.

Se ne riconosci tre insieme, ferma il progetto per una settimana. Non annullarlo: fermalo. Una settimana di pausa con una revisione seria costa cinque giornate. Continuare a spingere un progetto che non converge costa mesi, e la differenza fra chi si ferma e chi non si ferma non è la bravura del fornitore: è che qualcuno ha avuto il coraggio di dire che così non stava andando.

L'AI ha cambiato il conto, ma non dove pensi

Nel 2026 questa domanda arriva in tutte le trattative, e arriva quasi sempre in una forma sbagliata: "adesso che c'è l'AI, non dovrebbe costare meno?".

La risposta onesta è: in parte sì, e non nella parte che immagini.

Scrivere codice, oggi, è più veloce. Su lavori ripetitivi e ben delimitati, con strumenti usati bene, si guadagna parecchio: la struttura di un'applicazione, le schermate standard, le prove automatiche, la documentazione, la traduzione da un linguaggio all'altro. Ma la scrittura di codice nuovo, come dicevo, è il trenta-quaranta per cento del tempo di un progetto. Anche dimezzandola, il progetto non si dimezza: cala fra il quindici e il venticinque per cento, ed è comunque un risultato notevole.

Il resto del tempo, capire il problema, decidere, provare, correggere, coordinarsi, non è diminuito. In un caso è persino aumentato: rivedere codice prodotto in fretta richiede più attenzione, non meno, perché è plausibile anche quando è sbagliato.

Che cosa pretendere da un fornitore su questo

Non pretendere lo sconto: pretendi la velocità e la qualità. Un fornitore che usa bene questi strumenti nel 2026 ti fa vedere qualcosa di funzionante prima, ha una copertura di prove automatiche più alta di quella che aveva due anni fa, e produce documentazione senza che tu debba chiederla tre volte.

E pretendi due garanzie scritte, che sono diventate normali e che molti contratti non hanno ancora. La prima: il codice prodotto con assistenza automatica è comunque coperto dalle stesse garanzie di proprietà e di assenza di violazioni degli altri. La seconda: i tuoi dati, il tuo codice e i tuoi documenti non finiscono in servizi che li usano per addestrare modelli. Sono due righe, e un fornitore che ci ha già pensato le firma senza fare storie.

Chi invece ti offre uno sconto del sessanta per cento perché "tanto ora c'è l'AI" ti sta dicendo che ha ridotto le ore, non che è diventato più bravo. Il conto lo vedrai al terzo mese, quando qualcuno dovrà capire perché una funzione fa una cosa che nessuno ha deciso. Su come si mette al lavoro davvero questa roba dentro un team, con i criteri per giudicare il risultato, ho scritto intelligenza artificiale per programmare.

Un caso vero, con quello che ho sbagliato

Il progetto su misura più istruttivo che ho fatto è stato il mio: LegalDesk, una piattaforma per studi legali, multi-cliente, costruita da zero e poi venduta.

Quello che mi ha insegnato non riguarda la tecnologia. Riguarda dove finisce davvero il tempo, ed è la ragione per cui oggi, quando faccio una stima per qualcun altro, la faccio in modo diverso.

La parte che tutti immaginano come il prodotto, cioè le funzioni che l'utente vede e per cui paga, è stata meno della metà del lavoro. L'altra metà è andata in cose che nessun preventivo elenca e che nessun cliente vede: tenere separati i dati di studi diversi in modo che non si tocchino mai nemmeno per errore, l'accesso e i permessi fatti bene, il caricamento dei dati che gli studi si portavano dietro dai sistemi precedenti, gli abbonamenti e le fatture, e il pezzo che ho sottovalutato più di tutti, cioè cosa succede a un nuovo cliente nei primi trenta minuti in cui apre il programma per la prima volta.

Quel pezzo lì, l'ingresso, l'avevo trattato come un dettaglio da sistemare alla fine. Era invece la cosa che decideva se un cliente restava o spariva, e rifarlo dopo è costato molto più di quanto sarebbe costato pensarlo prima.

Ci sono due lezioni che porto in ogni progetto altrui.

La prima: il valore non sta nelle funzioni, sta nel passaggio. Un software si giudica dal momento in cui una persona ci arriva la prima volta e da quello in cui qualcosa va storto. Sono i due momenti che quasi tutti rimandano e sono i due che decidono se verrà usato.

La seconda: il costo di un software è dominato da quello che non si vede. Se in un preventivo la voce "dati esistenti", la voce "permessi" e la voce "che cosa succede quando qualcosa non funziona" valgono zero, quel preventivo non è più basso: è incompleto, e la differenza la metterai tu, in soldi o in mesi.

Che cosa fare lunedì mattina

Se stai valutando uno sviluppo su misura e vuoi partire con il piede giusto, questo è l'ordine che seguirei.

Scrivi il problema con un numero dentro. Mezz'ora. Se non riesci a metterci un numero, il progetto non è ancora maturo e la cosa più utile è misurare per un mese.

Guarda lavorare due persone. Un'ora ciascuna, senza interromperle. Annota le scorciatoie che usano: sono i requisiti veri.

Scrivi le due pagine. Un pomeriggio, le otto voci di sopra. È il documento che farà la differenza sui preventivi.

Chiedi tre offerte e leggi le domande. Non i prezzi per primi: le domande. Poi confronta i prezzi sapendo che cosa ognuno ha assunto.

Compra prima la chiarezza. Una fase iniziale corta a prezzo fisso, con un prodotto concreto: il rapporto sui dati, le integrazioni provate, la stima seria. Da tremila a ottomila euro che ti evitano di sbagliare la decisione da quarantamila.

Metti nel contratto le sette clausole. Codice tuo, archivio intestato a te dal primo giorno, dipendenze dichiarate, infrastruttura tua, dati esportabili, criteri verificabili, uscita descritta. Sono un'ora di lavoro con chi ti segue e valgono anni.

Metti a bilancio il secondo anno. Fra il quindici e il venticinque per cento all'anno per la manutenzione, più quello che decidi di spendere in evoluzione. Prima di firmare, non dopo.

Il punto, in breve

Lo sviluppo software su misura non è caro o economico in assoluto: è caro quando compri un progetto e conveniente quando compri un risultato che sai misurare. La differenza fra le due cose la fai tu prima di chiedere il primo preventivo, non il fornitore dopo.

I numeri da tenere a mente sono pochi. Una giornata di lavoro sta intorno ai cinquecento euro. Un progetto piccolo sta fra otto e venticinquemila, uno medio fra venticinque e ottantamila. La stima che ricevi va aumentata del settanta per cento per capire se il progetto regge davvero. E ogni anno, per restare vivo, il software costa fra il quindici e il venticinque per cento di quanto è costato costruirlo.

Le due mosse che rendono di più sono entrambe economiche e nessuna delle due è tecnica: scrivere due pagine oneste prima di chiedere le offerte, e comprare una prima fase corta di chiarezza invece di comprare tutto insieme.

E l'ultima, che è quella che vedo saltare più spesso. Il software su misura è tuo solo se il codice, l'infrastruttura e i dati sono intestati a te dal primo giorno. Se non lo sono, quello che hai comprato non è un software: è un abbonamento a un fornitore, con la differenza che il prezzo di rinnovo lo scoprirai quando non potrai più dire di no.