"Quanto costa fare un'app per gestire i miei ordini?" Chiedere un preventivo software senza contesto porta quasi sempre a una semplificazione forzata: il costo dipende da decisioni che emergono davvero solo quando si analizzano processi, eccezioni, integrazioni e vincoli.
Se invece mi dici quanto hai da investire, la conversazione diventa più utile: possiamo decidere insieme cosa costruire prima, cosa rimandare, quali trade-off accetti e come ridurre il rischio di sorprese.
È un modo più realistico di lavorare sul software.
Perché un preventivo “al buio” è fragile
Cosa stai comprando spesso non è ancora chiaro
Tu hai in testa un problema da risolvere. Tra problema e soluzione, però, ci sono molte scelte: permessi, eccezioni, integrazioni, flussi alternativi, requisiti non esplicitati.
“Gestione ordini” può voler dire cose molto diverse: un listino semplice o logiche di pricing piene di eccezioni, come succede quando il software finisce per codificare il caos; un'integrazione con la contabilità oppure un semplice export manuale; un portale clienti o una gestione tutta interna; una reportistica essenziale oppure analisi più avanzate.
Ogni risposta sposta costi e tempi. E molte risposte emergono durante l’analisi, non prima.
È lo stesso motivo per cui le stime nel software sono spesso imprecise: non è un lavoro “a pezzi indipendenti”, è esplorazione guidata.
Il preventivo fisso incentiva comportamenti difensivi
Quando il contratto è “scope fisso, prezzo fisso”, entrambe le parti iniziano a difendersi. Il fornitore aggiunge margine “di sicurezza” oppure sottostima e prova a recuperare dopo con le change request; il cliente, dal canto suo, cerca di infilare tutto possibile perché "tanto era incluso".
Non sempre succede, ma succede abbastanza spesso da rendere questo modello rischioso nei progetti dove i requisiti non sono già cristallizzati.
Perché parlare di budget migliora la qualità delle decisioni
Quando dici “ho 30.000 euro”, smettiamo di discutere di un software ideale e iniziamo a discutere di un software realistico.
1) Le priorità diventano visibili
Con un vincolo chiaro, possiamo separare ciò che è indispensabile da ciò che migliora il prodotto e da ciò che sarebbe solo comodo avere. In altre parole, emerge subito il nucleo senza cui il problema non si risolve, quello che conviene rimandare e quello che può aspettare senza danni.
Senza un vincolo, tutto tende a diventare “must”. Con un vincolo, il prodotto prende focus.
2) Posso proporti l’approccio adatto alla fascia
Un progetto da 10K e uno da 40K possono risolvere lo stesso problema, ma con strumenti diversi e con compromessi diversi. Come ho spiegato nell’articolo su preventivi 5K vs 50K, sono “prodotti” differenti.
Se non so il budget, rischio di proporti una soluzione troppo rigida, che poi esplode quando chiedi personalizzazioni, oppure una soluzione sovradimensionata, che ti fa spendere senza ottenere un valore proporzionato.
3) Possiamo essere espliciti sui limiti (ed evitare sorprese)
Esempio di conversazione utile: “Con 15K facciamo versione 1 con queste 3 funzionalità core, solide e usabili. La reportistica avanzata e il portale clienti sono fase 2, stimata 10–15K.”
Questo è più onesto di un “ti costa X” senza chiarire cosa resta fuori.
“Se ti dico il budget, lo userai tutto”
Obiezione legittima. E infatti serve una regola chiara: il budget non deve diventare il prezzo. Deve diventare il vincolo.
In pratica, prima definiamo un obiettivo minimo misurabile, cioè cosa deve fare la v1 per poter essere considerata un successo. Poi costruiamo una roadmap di opzioni, distinguendo chiaramente cosa aggiungere se resta budget e cosa rimandare se il margine si restringe. Infine rendiamo trasparente ciò che stiamo acquistando davvero: sviluppo, test, deploy e documentazione minima.
Nel software, “cose da fare” ce ne sono sempre più del budget disponibile. Il punto è spendere sulle cose con più ritorno.
Tre regole operative per farla funzionare davvero
La prima regola è definire un minimo non negoziabile: se il prodotto non riesce a fare il core flow, cioè il flusso principale che genera valore, costruire il resto non ha senso. La seconda è congelare lo scope, cioè il perimetro delle cose da fare, per blocchi brevi di due o tre settimane: consegni, misuri e solo dopo decidi cosa entra nel blocco successivo, in modo coerente con l’approccio lancia, ascolta, migliora. La terza è includere nel “minimo” anche continuità e controllo: repository tuo, accessi tuoi, deploy ripetibile, istruzioni di avvio in locale. Senza queste basi, stai solo comprando velocità oggi e fragilità domani.
Come funziona in pratica
Fase 1: problema + vincolo
“Questo è il problema, questo è il budget.” Una call focalizzata su flussi reali, eccezioni, integrazioni, utenti.
Fase 2: piano, non lista infinita
Una proposta seria esplicita cosa include la v1, cosa resta fuori, quali trade-off vengono accettati, quali sono tempi e milestone e cosa serve da te in termini di dati, accessi e decisioni. La differenza la fa proprio questa chiarezza.
Fase 3: iterazioni brevi
Ogni 2–3 settimane qualcosa di funzionante. Le priorità si aggiustano con costi visibili, non a fine progetto.
Fase 4: il budget finisce, il prodotto resta in piedi
Obiettivo: arrivare a fine budget con un prodotto utilizzabile, non con “tante cose a metà”.
Il budget non è solo un limite: è uno strumento di focus
La maggior parte dei progetti che vanno bene non ha un budget infinito. Ha un budget chiaro, obiettivi misurabili, priorità stabili per blocchi brevi e scelte esplicite su cosa rimandare. Questo riduce sprechi, rework e conflitti, e rende molto più probabile arrivare a qualcosa che funziona davvero per il business.
Simone Giusti
Consulente software strategico
