Imprenditori e responsabili IT spesso ricevono preventivi per la stessa app che differiscono di migliaia di euro. Non è un mistero: dipende da cosa davvero include ciascun preventivo. Questa guida ti mostra come leggere tra le righe, cosa chiedere e come confrontare proposte diverse senza basarsi solo sul prezzo.
Panoramica in 20 secondi
Un preventivo serio non nasce da una cifra buttata lì. È il risultato di una scomposizione sistematica del progetto, partendo dal quadro generale e scendendo nei dettagli. L'architetto software identifica prima gli epic, cioè le aree funzionali principali: ad esempio, in un'app di gestione magazzino, gli epic potrebbero essere "Inventario", "Ordini Cliente", "Reportistica", "Integrazioni Contabili".
Ogni epic viene scomposto in user story, racconti brevi che descrivono una funzionalità dal punto di vista di chi la usa: "Come magazziniere, voglio poter scansionare un codice a barre per aggiornare la quantità disponibile, così da avere dati sempre sincronizzati". Infine, ogni user story si traduce in task tecnici specifici: creare il servizio backend di lettura del barcode, sviluppare l'interfaccia di input sulla app, testare l'integrazione con lo scanner Bluetooth, documentare il flusso.
È questo lavoro preliminare, spesso invisibile al cliente, che consente al team tecnico di stimare il tempo reale. Se saltate questa fase e ricevete preventivi "al dettaglio" senza una chiara mappa dell'architettura, significa che chi ha risposto non ha fatto i compiti a casa.
La stima dell'effort, cioè il tempo necessario per completare ogni attività, usa metodi che vanno oltre il tirare a indovinare. Il più comune tra le aziende serie è il t-shirt sizing: ogni task viene classificato come XS (1-2 giorni), S (3-5 giorni), M (una settimana), L (due settimane), XL (un mese) e oltre.
Questo approccio funziona perché evita di fingere una precisione che non esiste: non potete prevedere il futuro al giorno, ma potete dire con ragionevole sicurezza che una funzionalità richiede più di una settimana ma meno di due. Alcuni team usano il planning poker, una tecnica collaborativa in cui gli sviluppatori, dopo aver discusso una user story, votano contemporaneamente la loro stima.
Se le stime divergono molto, il team discute i motivi finché non raggiunge un consenso. Questo metodo riduce i bias individuali e cattura meglio le complessità nascoste. Il risultato della stima viene moltiplicato per il costo orario medio del team (che varia da 50-70 euro l'ora per junior fino a 100-150 per senior) e potete finalmente leggere il preventivo: se una user story richiede 40 ore di lavoro e il vostro team costa 80 euro l'ora, leggete 3.200 euro.
Ma qui arriva il punto che fa scappare i clienti delle app «low-cost»: tutto quello appena descritto copre solo lo sviluppo delle funzionalità visibili. Ci sono attività altrettanto critiche che i preventivi al ribasso dimenticano spesso.
La preparazione dell'infrastruttura cloud: server, database, distribuzione dei contenuti. I controlli automatici sul codice, così che ogni modifica venga verificata prima di arrivare in produzione.
I test seri, a tre livelli: test delle singole funzioni, test di come i moduli lavorano insieme, test dell'intero percorso utente. E poi le revisioni del codice tra sviluppatori, la verifica di sicurezza da parte di specialisti che cercano vulnerabilità, la documentazione tecnica completa per la manutenzione futura.
Infine la messa in produzione, la pubblicazione sugli store (Apple e Google hanno processi di approvazione lunghi) e la formazione degli utenti interni o dei clienti finali. Un'app priva di questi elementi funzionerà per tre mesi, poi diventerà un disastro di manutenzione.
Se un preventivo non menziona nessuna di queste voci, non è un preventivo completo: vi state comprando solo la versione beta di un software, non il prodotto finito.
Raccontaci il processo in mezz'ora e ti diciamo cosa si automatizza per primo, con i numeri della tua azienda.
Ricevere tre preventivi diversi per la stessa app e trovarsi con differenze folli non è raro: dipende interamente da come avete comunicato i requisiti. Se il vostro brief dice semplicemente "un'app per gestire la vendita al dettaglio", ogni sviluppatore immaginerà una versione completamente diversa.
Uno penserà a un'app con magazzino integrato, un altro senza. Uno magari dà per scontato il pagamento online, un altro prevede solo il pagamento alla consegna. Per evitare questo, il brief deve includere alcuni elementi precisi.
Primo: schizzi o bozze delle schermate, anche solo disegnati su carta (non vi servono strumenti professionali, serve solo che il team di sviluppo capisca il flusso). Secondo: la lista delle funzionalità con priorità chiara, separando quelle indispensabili, senza le quali l'app non ha senso, da quelle belle da avere ma non essenziali.
Terzo: le specifiche dei sistemi con cui l'app deve comunicare. Se deve integrarsi con SAP, Zucchetti, HubSpot o con il vostro gestionale, il team ha bisogno della documentazione tecnica per sapere come collegarsi.
Aggiungete i vincoli noti, come "i nostri clienti usano prevalentemente telefoni Android con versione 9", una data indicativa del lancio e il budget di riferimento, senza nasconderlo: un conto è partire dai 5.000 euro di un'app semplice, un altro è avere spazio per fare di più fin da subito.
Un preventivo preciso è costruito dall'alto verso il basso, non al contrario. Significa che il team di sviluppo non inventa i numeri, ma parte dall'architettura, passa per le user story, stima ogni task e somma tutto.
Quando ricevete il preventivo, potete verificare questa logica facendo domande specifiche: "Vedo che il backend costa 15.000 euro. Quali moduli include esattamente? Quanti punti di collegamento verso altri sistemi?
Quante tabelle di database?". Se il fornitore risponde con precisione, significa che ha fatto il lavoro. Se si stringe nelle spalle o si infastidisce alla domanda, scappate. Una buona pratica è chiedere anche la ripartizione per categorie: quanto per lo sviluppo delle funzionalità, quanto per i test, quanto per l'infrastruttura, quanto per documentazione e formazione.
La trasparenza è sinonimo di professionalità. Attenzione anche alle stime espresse solo come cifra unica e tonda: un preventivo serio riporta i giorni uomo per attività, le tariffe applicate e le ipotesi assunte, così quando il perimetro cambia potete rinegoziare sui numeri e non sulle impressioni.
Conservate infine le risposte scritte del fornitore alle vostre domande: diventeranno parte integrante del contratto e vi tuteleranno in caso di contestazioni.
Confrontare preventivi significa costruire una griglia di valutazione su dieci criteri. L'esperienza del team nel vostro settore: una software house che ha fatto 50 app bancarie è diversa da una che ne ha fatte 5.
Le referenze verificabili di clienti simili ai vostri. Le tecnologie scelte e le motivazioni: perché usare React invece di Flutter, e perché quella scelta è meglio per i vostri clienti.
La percentuale e il tipo di test inclusi: se non vi dicono esplicitamente che il codice avrà almeno il 70% di copertura, non è serio. Le garanzie sul supporto post-lancio: quanto tempo ci mettono a risolvere un problema critico, ed è incluso il primo anno?
E ancora: trasparenza totale dei costi senza voci generiche, velocità di risposta alle vostre domande (un team professionale risponde in 24 ore), processo di gestione del progetto (come rimanete informati sugli avanzamenti?), regole scritte per le modifiche in corso d'opera (cosa succede se cambiate idea durante il progetto?). Italy Soft, ad esempio, struttura il processo di preventivazione proprio intorno a questa trasparenza: ricevete una decomposizione completa in epic e user story, dettagli su ogni fase di test, un calendario con tappe chiare e revisioni settimanali.
Quando confrontate su questi criteri, il prezzo più basso smette di essere il fattore decisivo e diventa una scelta consapevole.
Se mancano due o più voci, state confrontando prodotti diversi allo stesso prezzo apparente: chiedete l'integrazione delle voci mancanti prima di decidere in base al costo.
Epic, user story e task tecnici vengono identificati sistematicamente per evitare sorprese e per permettere una stima di effort affidabile. Ogni voce del preventivo corrisponde a attività reali, verificabili e tracciabili.
T-shirt sizing e planning poker sono tecniche che i team esperti usano per stimare il tempo senza fingere precisione falsa. Questo riduce i rischi di preventivi irrealistici e slittamenti di timeline.
Test automatizzati, security review, CI/CD pipeline, documentazione tecnica, deploy e formazione degli utenti non sono optional: sono la differenza tra un'app che funziona tre mesi e un software sostenibile nel tempo.
Italy Soft costruisce ogni preventivo partendo dall'architettura, passa per user story, stima ogni task e dettagli testing e supporto incluso. Il cliente vede esattamente cosa paga e perché, evitando sorprese in corso d'opera.
Redazione a cura di Italy Soft, con il supporto di strumenti di intelligenza artificiale e revisione editoriale umana.
Italy Soft
In 30 minuti di audit gratuito analizziamo i tuoi processi e calcoliamo il ROI concreto. Nessun impegno.