Preventivo per Software su Misura: Come si Legge Prima di Firmarlo

Due preventivi per lo stesso software: 18.000 e 47.000 euro. Succede regolarmente, e la reazione istintiva è pensare che uno dei due stia esagerando.

Quasi sempre non è così. Stanno rispondendo a due domande diverse, perché nessuno ha scritto con precisione quale fosse la domanda. E il modo per capire quale dei due ti servirà davvero non è guardare il totale: è guardare cosa c'è sotto.

Questa è la griglia che uso quando un cliente mi chiede di leggere un preventivo altrui.

Prima del preventivo viene il documento di scope

Se hai chiesto un'offerta descrivendo il progetto a voce o con una mail di dieci righe, i numeri che ricevi non sono confrontabili. Non perché i fornitori siano disonesti, ma perché ognuno ha riempito i buchi con le proprie assunzioni.

Un fornitore che lavora bene, prima di quotare, produce un documento che elenca cosa farà il software e cosa non farà. Non deve essere lungo: due o tre pagine bastano. Deve contenere gli utenti e i loro ruoli, le funzioni divise per priorità, i dati che entrano e da dove, quelli che escono e verso dove, e una lista esplicita di cosa resta fuori.

Quella lista di esclusioni è la parte più preziosa del documento, ed è quella che tutti dimenticano. Senza, ogni discussione futura su "ma io pensavo che ci fosse anche..." diventa una trattativa a progetto avviato, cioè nel momento in cui hai meno potere contrattuale di tutti.

Se un fornitore ti manda un numero senza aver prodotto questo documento, non hai un preventivo: hai una speranza con un prezzo attaccato.

Se stai ancora scegliendo, prima leggi l'altra guida

Questo pezzo dà per assodato che tu abbia già deciso di far sviluppare qualcosa e ti trovi dei preventivi in mano. Se sei un passo indietro — devi ancora capire quale strada prendere, se un prodotto pronto basti, quali criteri usare per confrontare le soluzioni — la guida giusta è un'altra: come scegliere il software gestionale per la tua PMI.

Qui si parla solo di cosa c'è scritto nel documento che stai per firmare.

Le sei domande che separano un fornitore dall'altro

Chi possiede il codice quando abbiamo finito? È la domanda che fa più male e che quasi nessuno pone. La risposta deve essere scritta nel contratto. Se il codice resta del fornitore, ogni evoluzione futura passa obbligatoriamente da lui, a qualunque prezzo decida. Non è illegittimo, ma cambia completamente il valore di quello che stai comprando.

Dove finiscono i miei dati e in che formato posso riprenderli? Un software che non permette di esportare i propri dati in un formato leggibile è una gabbia. Chiedi di vedere un export di esempio, non una rassicurazione.

Chi ha lavorato ai progetti che mi state mostrando? Le referenze si riferiscono all'azienda, il lavoro lo fanno le persone. Se il team che ha realizzato il caso di successo non c'è più, quella referenza vale poco.

Cosa succede se durante il progetto ci accorgiamo che serve una cosa diversa? Nessun progetto software finisce come era stato disegnato. La domanda non è se ci saranno variazioni ma come vengono gestite: chi le valuta, con quale processo, e a che tariffa. Un fornitore che dice "vedremo strada facendo" ti sta preparando una trattativa a metà progetto.

Come lavorate nei rilasci? Consegna unica alla fine o rilasci intermedi che puoi provare? La seconda è quasi sempre preferibile, perché ti fa scoprire i fraintendimenti quando costa poco correggerli.

Che succede il giorno dopo la consegna? Chi corregge i difetti, entro quanto, e per quanto tempo senza costi aggiuntivi. Deve esserci un periodo di garanzia con tempi dichiarati, e un piano di manutenzione successivo con numeri, non con buone intenzioni.

Le due voci che nel 2026 vanno chieste esplicitamente

Il 2026 ha portato due cose nuove che nei preventivi non compaiono ancora e che invece vanno chiarite.

Gli agenti AI dentro i gestionali. Diversi prodotti hanno introduzione di funzioni che non si limitano a suggerire ma eseguono: ordini, solleciti, riconciliazioni. Se il fornitore te ne parla, chiedi due cose concrete — quali azioni l'agente può compiere senza approvazione umana, e dove finiscono i dati che elabora. La prima è una questione di controllo operativo, la seconda di conformità.

L'AI Act. Se il software incorpora funzioni di intelligenza artificiale, esistono obblighi di trasparenza verso gli utenti che dipendono da come quelle funzioni vengono usate. Va chiarito in fase di contratto chi se ne fa carico: il fornitore che l'ha sviluppata o tu che la utilizzi.

Sono domande che oggi mettono in difficoltà molti fornitori, e proprio per questo separano bene chi sa cosa sta vendendo da chi ripete quello che ha letto.

Come si legge la stima di sforzo

Nei preventivi seri c'è una tabella con i moduli e le giornate stimate. È la parte che dice di più sul fornitore, molto più del totale in fondo.

Guarda il rapporto tra sviluppo e il resto. Se un preventivo mette il 95% delle giornate sullo sviluppo puro, mancano analisi, test, migrazione dei dati e formazione — che sono lavoro vero e che qualcuno dovrà fare comunque. Su un progetto sano lo sviluppo pesa intorno al 55-65%, il resto si divide fra analisi iniziale, collaudo e avviamento.

Cerca la voce migrazione dati. È quella che manda fuori budget più progetti di qualsiasi altra. I dati di partenza non sono mai puliti come si pensa: anagrafiche duplicate, campi usati per scopi diversi da quelli previsti, storici incompleti. Se nel preventivo la migrazione vale due giornate, o il fornitore non ha guardato i dati o li ha guardati e non ti sta dicendo cosa ha visto.

Cerca la voce formazione. Un gestionale che nessuno sa usare è un costo puro. Le ore di affiancamento nelle prime settimane valgono più di due funzioni in più.

E controlla che ci sia una riga per il collaudo con dati veri, non con dati di prova. È il momento in cui saltano fuori i casi particolari che nessuno aveva raccontato in fase di analisi, e capita sempre.

Le clausole che cambiano il prezzo dopo la firma

Il totale del preventivo è il prezzo di partenza. Quello finale lo decidono quattro clausole che stanno più in fondo e che quasi nessuno legge.

Come si gestiscono le variazioni. Nessun progetto software finisce come era stato disegnato. La domanda non è se ci saranno variazioni, ma con quale processo vengono valutate e a che tariffa. Deve essere scritta una cifra oraria o giornaliera, non "da concordare": concordare a progetto avviato significa concordare quando hai già speso metà budget e non puoi tornare indietro.

Cosa si considera consegnato. Serve un criterio di accettazione esplicito: quali casi devono funzionare perché una fase sia chiusa. Senza, la discussione su "è finito o no" diventa un braccio di ferro senza arbitro, e la fattura arriva comunque.

Come sono legati i pagamenti agli stati di avanzamento. Le rate devono seguire consegne verificabili, non il calendario. Pagare al 30-40-30 su consegne reali è sano; pagare a scadenze fisse indipendentemente da cosa è stato consegnato sposta tutto il rischio su di te.

Cosa copre la garanzia e per quanto. I difetti scoperti dopo l'avvio si correggono senza costi per un periodo dichiarato, e va distinto cosa è difetto — non fa quello che era stato concordato — da cosa è variazione. È la distinzione su cui nasce la maggior parte delle discussioni post consegna, e metterla per iscritto prima costa cinque minuti.

Un'ultima voce da cercare, e se non c'è va aggiunta: cosa succede se il progetto si interrompe. Chi tiene cosa, in che stato viene consegnato quello che è stato fatto, e con quale documentazione. Nessuno lo mette volentieri, ed è esattamente il motivo per cui serve.

Il segnale che vale più di tutti

Se dovessi tenere un solo criterio, terrei questo: un buon fornitore ti dice di no almeno una volta durante la trattativa.

Ti dice che una funzione che chiedi non serve, che una parte conviene farla con un prodotto pronto invece che sviluppata, che il progetto così com'è disegnato costa troppo per il ritorno che porta.

Chi dice sì a tutto non ti sta assecondando: ti sta preparando un progetto che non riuscirà a consegnare come promesso, e la conversazione difficile arriverà comunque, solo più tardi e con i tuoi soldi già impegnati.

Come lavoriamo

Partiamo da un'analisi dei processi attuali con management e operativi, per capire dove sono davvero le inefficienze e cosa il software dovrebbe risolvere. Da lì esce un documento di scope condiviso, con la stima di sforzo divisa per moduli, e un preventivo dettagliato che spacchetta le voci invece di presentare una cifra unica.

Capita spesso che da quell'analisi esca che una parte conviene tenerla su un prodotto pronto. Lo diciamo, anche quando significa un progetto più piccolo per noi.

Scopri come sviluppiamo software gestionale →

Se hai un preventivo in mano e vuoi un parere prima di firmare, scrivici: leggerlo insieme costa meno di scoprire dopo cosa non c'era scritto.