“Quanto costa sviluppare questo software?” è la domanda a cui rispondiamo più spesso in Soamee. E la risposta onesta inizia sempre allo stesso modo: dipende. Ma “dipende” non può essere la fine della conversazione, quindi in questo articolo apriamo la nostra cucina: il metodo passo dopo passo che usiamo per stimare un budget di sviluppo software, le variabili che muovono davvero il prezzo e come riconoscere i preventivi trappola.
Se cerchi cifre concrete per tipo di progetto, abbiamo una guida complementare con i range di mercato: quanto costa sviluppare un’app nel 2026. Qui ci concentriamo sul metodo: come si costruisce quel numero.
Le variabili che muovono davvero il prezzo
Un budget software non si calcola per schermate né per “pagine”. Queste sono le variabili con il maggiore impatto, ordinate per peso reale nella nostra esperienza:
| Variabile | Impatto sul prezzo | Perché |
|---|---|---|
| Integrazioni esterne (ERP, CRM, pagamenti, API di terzi) | Molto alto | Ogni sistema esterno porta sorprese: documentazione povera, limiti, sandbox che non replica la produzione |
| Logica di business complessa | Molto alto | Regole, eccezioni e casi limite moltiplicano il lavoro invisibile |
| Sicurezza e conformità (GDPR, sanità, fintech) | Alto | Audit, cifratura, tracciabilità, anonimizzazione: lavoro che non si vede nella demo |
| Numero di ruoli e permessi | Alto | Ogni ruolo moltiplica i flussi da progettare e testare |
| Design su misura vs design system esistente | Medio-alto | Progettare da zero aggiunge settimane di lavoro iterativo |
| Multilingua e localizzazione | Medio | Non è solo tradurre: formati, valute, rotte, SEO per lingua |
| Numero di schermate | Medio | Conta, ma molto meno di quanto si creda |
| App native vs web | Medio | Due piattaforme native ≈ 1,6-1,8x il costo di una |
La conclusione pratica: due progetti con le stesse schermate possono differire di 3x nel prezzo per ciò che accade sotto la superficie.
Il nostro metodo di stima, passo dopo passo
Passo 1: Capire il problema, non la soluzione
La prima riunione non riguarda le feature, riguarda il business: quale problema risolve il software, chi lo userà, cosa succede se non viene costruito. Molti progetti diventano più economici proprio qui, perché la soluzione che il cliente aveva in testa era più grande del suo problema reale.
Passo 2: Definire l’ambito in storie, non in schermate
Scomponiamo il prodotto in user story (“come manager, voglio approvare fatture dal telefono”) raggruppate in epiche. Questo inventario è la colonna vertebrale del budget: tutto ciò che c’è viene stimato; tutto ciò che non c’è resta esplicitamente fuori.
Passo 3: Stimare per range con il team che eseguirà
Ogni epica viene stimata dal team tecnico che la costruirà (non da un commerciale), in range ottimista-pessimista. Usiamo i dati di progetti precedenti simili come calibrazione: la memoria storica vale più di qualsiasi formula.
Passo 4: Aggiungere il lavoro invisibile
È qui che i preventivi economici barano. Un progetto professionale include voci che non sono “feature”:
- Gestione e comunicazione: 10-15% del totale
- QA e testing: 15-25% secondo la criticità
- DevOps e deploy: CI/CD, ambienti, monitoraggio
- Buffer di incertezza: 10-20% a seconda di quanto l’ambito sia chiuso
Se un preventivo non dettaglia queste voci, o sono nascoste nel prezzo o sono semplicemente assenti (e le pagherai dopo, in bug e ritardi).
Passo 5: Presentare un range con assunzioni esplicite
Il risultato non è mai “42.500 €”. È qualcosa come: “Tra 35.000 e 48.000 €, assumendo che il gateway di pagamento sia Stripe, che il design parta dal vostro sistema attuale e che l’integrazione con l’ERP esponga un’API REST documentata”. Ogni assunzione che si rompe muove il numero, e tutti sappiamo in anticipo quali sono.
Perché un range ampio è segno di onestà
Sembra controintuitivo: un’agenzia esperta non dovrebbe darti una cifra esatta? Non all’inizio — e chi lo fa ti sta raccontando una favola.
L’incertezza all’inizio di un progetto software è un fatto misurabile, non una scusa. Il classico “cono di incertezza” dell’ingegneria del software mostra che le stime iniziali possono facilmente deviare tra 0,5x e 2x finché l’ambito non si chiude. Di fronte a questo ci sono tre risposte possibili:
- Cifra esatta e bassa → esca commerciale; il margine si recupera con gli “extra” a metà progetto
- Cifra esatta e gonfiata → hanno inserito un cuscinetto enorme senza dirtelo; paghi l’incertezza anche se non si materializza
- Range onesto con assunzioni → ti dicono la verità e ti danno il meccanismo per restringere il range (chiudere l’ambito, fare una fase di discovery)
Il range si restringe con il lavoro: dopo una fase di discovery o un primo sprint, la stima del resto guadagna moltissima precisione. Diffida della precisione prematura, non del range.
Come confrontare i preventivi di più agenzie
Ricevere tre preventivi e ordinarli per prezzo è il modo peggiore di decidere. Confronta con questa checklist:
- Ambito equivalente: hanno stimato la stessa cosa? Chiedi il dettaglio per epiche/moduli e verifica cosa include ciascuno
- Voci invisibili: compaiono QA, gestione, deploy e documentazione? O il prezzo è solo “programmare”?
- Assunzioni per iscritto: cosa hanno dato per scontato? È lì che vivono le discussioni future
- Team concreto: chi lavorerà sul tuo progetto (seniority, dedizione)? Un prezzo basso con profili junior senza supervisione costa caro
- Cosa succede con i cambiamenti: come si gestiscono e si valorizzano le modifiche di ambito?
- Proprietà e uscita: il codice è tuo dal primo giorno? Repository sotto il tuo account?
- Modello di lavoro: prezzo chiuso, time & materials o team dedicato — ognuno distribuisce il rischio in modo diverso
Su quest’ultimo punto: il prezzo chiuso trasferisce il rischio all’agenzia (che lo fa pagare come cuscinetto), e il time & materials lo trasferisce al cliente (che ha bisogno di fiducia e visibilità). Per progetti con incertezza, un ibrido ragionevole è discovery a prezzo chiuso + sviluppo per sprint.
Se stai valutando anche l’alternativa di assumere internamente, abbiamo un confronto completo tra agenzia vs team interno.
Red flag in un preventivo software
- Prezzo molto al di sotto degli altri senza spiegazione strutturale (posizione, ambito minore): di solito finisce in extra o in cattiva qualità
- Cifra esatta senza requisiti chiusi: precisione prematura = marketing
- Nessun dettaglio: un unico numero totale impedisce di confrontare e negoziare
- Nessuna assunzione né esclusione: tutto ciò che non è scritto finirà in discussione
- QA e gestione “inclusi gratis”: non esistono gratis; o non si fanno o sono nascosti
- Pressione per firmare subito con sconti in scadenza: le decisioni da decine di migliaia di euro non si prendono con urgenza artificiale
- Tutto è “sì”: un’agenzia che non mette mai in discussione il tuo ambito non sta stimando, sta vendendo
E le green flag
- Ti fanno molte domande prima di dare un numero
- Ti propongono di tagliare l’ambito per adattare il budget (venderti meno è il miglior segnale di onestà)
- Range con assunzioni esplicite e piano per restringerlo
- Dettaglio trasparente che include QA, gestione e deploy
- Referenze verificabili di progetti di dimensioni simili
Domande frequenti
Perché le agenzie danno range invece di una cifra chiusa?
Perché all’inizio c’è incertezza reale: requisiti non chiusi, integrazioni da scoprire. Un range onesto riflette quell’incertezza; una cifra esatta prima di definire l’ambito è marketing, non stima.
Come confronto i preventivi di più agenzie?
Confronta l’ambito, non solo il prezzo: dettaglio per voci, assunzioni, team concreto e gestione dei cambiamenti. Due preventivi con la stessa cifra possono coprire ambiti radicalmente diversi.
Cosa rende più caro un progetto?
Integrazioni esterne, sicurezza e conformità, logica di business complessa e cambi di ambito a metà progetto. Il numero di schermate conta meno di quanto si creda.
Un preventivo molto più economico è un cattivo segnale?
Quasi sempre: ambito mal compreso, tagli sulla qualità o extra futuri. Chiedi il dettaglio e le assunzioni prima di decidere in base al prezzo.
Conclusione
Un buon budget software non è una cifra: è un ambito scomposto, stimato da chi lo eseguirà, con il lavoro invisibile incluso e le assunzioni per iscritto. Il range ampio all’inizio non è debolezza, è onestà; la precisione arriva quando l’ambito si chiude, non prima.
Se hai un progetto tra le mani e vuoi vedere questo metodo applicato al tuo caso, prenota una consulenza gratuita: uscirai con un range realistico e con le domande giuste per valutare qualsiasi preventivo tu riceva — nostro o di altri.