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 sola figura. È il risultato di una decomposizione sistematica del progetto, partendo dal grande quadro 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 task, usa metodi che vanno oltre l'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 di app «low-cost»: tutto quello appena descritto copre solo lo sviluppo delle funzionalità visibili. Attività altrettanto critiche e spesso dimenticate nei preventivi a ribasso includono setup dell'infrastruttura cloud (server, database, CDN per media), configurazione di pipeline CI/CD automatiche (così che ogni nuovo codice venga testato automaticamente prima di arrivare a produzione), testing serio: unit test (test delle singole funzioni), integration test (test di come moduli diversi lavorano insieme), e2e test (test dell'intero flusso utente), code review strutturate tra sviluppatori, security review da parte di specialisti che cercano vulnerabilità, documentazione tecnica completa per manutenzibilità futura, orchestrazione del deploy in produzione, submission alle app store (Apple e Google hanno processi di approvazione lunghi), formazione degli utenti interni o clienti finali. Un'app che non ha alcuno 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.
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 assume online payment, un altro assume solo pagamento offline. Per evitare questo, il brief deve includere: wireframe o mockup, anche solo disegnati su carta — non vi serve Figma, serve solo il team di sviluppo capisca il flusso; lista di funzionalità con priorità chiara, separando must-have (funzionalità senza le quali l'app non ha senso) da nice-to-have (belle da avere ma non essenziali), specifiche dei sistemi con cui l'app deve comunicare — se deve integrarsi con SAP, Zucchetti, HubSpot o quale sia il vostro ERP, allora il team ha bisogno della documentazione API per sapere come collegarsi; vincoli tecnici noti, come "i nostri clienti usano prevalentemente telefoni Android con versione 9", timeline indicativa del lancio, budget target non nascosto — sapere se disponete di 20.000 o 100.000 euro cambia radicalmente la proposta.
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? Quante API endpoints? Quante tabelle di database? Quanti integrazioni con sistemi terzi?". Se il fornitore risponde con precisione, significa che ha fatto il lavoro. Se fa di spalla o si arrabbia alla domanda, scappate. Una buona pratica è chiedere anche il breakdown per categorie: quanto per sviluppo delle funzionalità, quanto per testing, quanto per infrastruttura, quanto per documentazione e formazione. Trasparenza è sinonimo di professionalità.
Confrontare preventivi significa costruire una matrice di valutazione basata su dieci criteri: esperienza del team nel vostro settore (una software house che ha fatto 50 app bancarie è diversa da una che ne ha fatte 5), referenze verificabili di clienti simili ai vostri, stack tecnologico scelto e motivazioni (perché usare React invece di Flutter? Perché quella scelta è meglio per i vostri clienti?), percentuale e tipo di testing incluso (se non vi dicono esplicitamente che il codice avrà almeno il 70% di copertura, non è serio), SLA del supporto post-lancio (quanto tempo ci mettono a risolvere un bug critico? È incluso il primo anno?), trasparenza totale dei costi senza voci generiche, velocità di risposta alle vostre domande (un team professionale risponde in 24 ore), processo di gestione progetto (come rimanete informati sugli avanzamenti?), politica di change management (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 testing, timeline con milestone chiari e revisioni settimanali. Quando confrontate su questi criteri, il prezzo più basso smette di essere il fattore decisivo e diventa una scelta consapevole.
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.
Italy Soft
In 30 minuti di audit gratuito analizziamo i tuoi processi e calcoliamo il ROI concreto. Nessun impegno.