Quanto costa sviluppare un’app? Metodo per stimare il progetto

Tre esempi di stima dell’app (non prezzi medi di mercato)

I numeri seguenti sono ipotesi didattiche per mostrare il calcolo: non sono prezzi medi di mercato, tariffari, preventivi né risultati di clienti. In ogni scenario le giornate comprendono, nell’ordine, analisi, UX/UI, sviluppo, integrazioni, QA e rilascio; IVA, servizi ricorrenti e commissioni degli Store restano esclusi.

1. Scope essenziale: 6 + 8 + 30 + 6 + 8 + 3 = 61 giornate. Con una tariffa ipotetica di 450 €/giorno, il lavoro vale 61 × 450 € = 27.450 €. Una riserva esplicita del 10% vale 2.745 €; budget prudente: 30.195 €.
2. Prodotto con più flussi e API: 10 + 12 + 55 + 18 + 14 + 5 = 114 giornate. Con 520 €/giorno, il lavoro vale 59.280 €. Riserva del 15%: 8.892 €; budget prudente: 68.172 €.
3. Sistema più articolato su due piattaforme: 16 + 18 + 95 + 30 + 24 + 8 = 191 giornate. Con 600 €/giorno, il lavoro vale 114.600 €. Riserva del 20%: 22.920 €; budget prudente: 137.520 €.

Questi totali cambiano appena cambia una sola assunzione. Per confrontare offerte, sostituisci giornate, tariffa e riserva con valori dichiarati dal fornitore e verifica cosa è incluso in ogni fase.

Come leggere una stima

Una stima iniziale non è una promessa matematica: è la conseguenza delle informazioni disponibili. Deve dichiarare il livello di precisione e le assunzioni. «Il cliente fornisce testi definitivi», «l’API dispone di un ambiente di test» e «non è richiesta sincronizzazione offline» sono condizioni che modificano il lavoro se risultano false.

Esistono tre modi comuni per organizzare l’incarico. Uno scope fisso funziona quando flussi e criteri di accettazione sono stabili. Una fase di discovery a prezzo definito riduce l’incertezza e produce specifiche, prototipo e piano prima dello sviluppo. Un accordo a tempo e materiali si adatta a prodotti che devono evolvere mentre vengono validati, ma richiede priorità, budget periodico e visibilità continua sul lavoro completato. Nessun modello è sempre migliore: deve corrispondere alla quantità di decisioni ancora aperte.

Il preventivo dovrebbe associare ogni fase a un deliverable osservabile: mappa dei flussi approvata, prototipo testabile, build distribuita, integrazione verificata o release candidata. I pagamenti possono seguire queste tappe, evitando percentuali scollegate dal risultato. La guida al preventivo di sviluppo software raccoglie clausole, consegne, proprietà ed esclusioni da controllare prima della firma.

Definisci anche la gestione delle modifiche. Una richiesta non è automaticamente un extra: può essere una correzione se il comportamento viola un criterio concordato. Diventa variazione di scope quando introduce un nuovo flusso, cambia un’integrazione o modifica un requisito approvato. Un registro con decisione, impatto e approvazione protegge entrambe le parti e mantiene attendibile la previsione.

Perché due app simili hanno costi diversi

Due interfacce con lo stesso numero di schermate possono richiedere un lavoro molto diverso. Una schermata informativa legge contenuti statici; una schermata di pagamento deve gestire stati, errori, sicurezza, ricevute e regole dello store. Una lista locale è semplice; una lista condivisa tra più utenti richiede account, permessi, database, sincronizzazione e gestione dei conflitti.

Le variabili che cambiano davvero la stima sono:

• quantità e complessità dei flussi, non il numero grezzo di schermate;
• ruoli e permessi: cliente, operatore, amministratore o altri profili;
• dati locali, cloud o sincronizzati anche offline;
• API esterne, pagamenti, mappe, notifiche, fotocamera o sensori;
• pannello web necessario per gestire utenti e contenuti;
• importazione di dati esistenti e qualità delle fonti;
• requisiti di privacy, accessibilità e sicurezza;
• piattaforme, dispositivi e versioni da supportare;
• livello di test, osservabilità e assistenza richiesto.

Per questo «voglio un’app simile a…» non basta. Il prodotto citato mostra soltanto la superficie; non rivela infrastruttura, regole, strumenti interni e manutenzione.

Definire il risultato prima delle funzioni

Un brief utile comincia con una frase misurabile: «consentire a questo tipo di utente di completare questa attività senza questo passaggio manuale». Poi descrive il percorso minimo dall’apertura al risultato.

Per un MVP, ogni funzione dovrebbe superare tre domande:

1. senza questa funzione l’utente può ottenere il valore principale?
2. esiste un’alternativa manuale accettabile nella prima versione?
3. il suo utilizzo può essere verificato dopo il rilascio?

Se la risposta indica che la funzione non è essenziale, può entrare in una fase successiva. MVP non significa prodotto fragile: significa perimetro ridotto, con qualità sufficiente per essere usato e misurato. Login, recupero account, consenso, stati vuoti, errori e assistenza non sono rifiniture quando il flusso dipende da loro.

Un deliverable utile dell’analisi è una mappa con utenti, azioni, dati, eccezioni, dipendenze e criteri di accettazione. Da questa mappa nasce il backlog stimabile.

App iOS, Android o multipiattaforma

La scelta tecnologica deve seguire utenti e requisiti, non una promessa generica di risparmio. Lo sviluppo nativo consente accesso diretto agli strumenti e ai pattern della piattaforma. Un approccio multipiattaforma può condividere parte del codice e mantenere esperienze coerenti, ma non elimina test per piattaforma, configurazione degli store e interventi nativi quando servono.

Se la decisione è ancora aperta, la matrice web app o app nativa confronta distribuzione, SEO, offline, API del dispositivo e velocità di aggiornamento senza confondere architettura e prezzo.

Apple pubblica le proprie Human Interface Guidelines e le App Review Guidelines. Influenzano navigazione, account, acquisti, privacy e contenuti fin dalla progettazione. Per Android, la documentazione ufficiale descrive il flusso di preparazione e distribuzione su Google Play.

Fasi da trovare nel preventivo

Analisi tecnica e funzionale

Chiarisce obiettivi, attori, dati, vincoli e criteri di accettazione. Include verifica di API e servizi esterni. Una stima senza analisi può essere solo preliminare, perché lascia irrisolti i punti che generano variazioni.

UX, prototipo e UI

La UX ordina i passaggi; il prototipo permette di testarli prima del codice; la UI definisce componenti, stati e comportamento responsive. Il preventivo deve chiarire se include wireframe, interfaccia completa, design system o adattamento di materiali già pronti.

Sviluppo dell’app e del backend

L’app visibile è una parte del sistema. Account, database, autorizzazioni, notifiche, file, pagamenti e log possono richiedere un backend. Va chiarito chi gestisce hosting, ambienti, credenziali, dominio, email transazionali e servizi terzi.

Integrazioni e migrazione

Una API documentata e stabile è diversa da un’integrazione da scoprire durante il progetto. Prima della stima vanno controllati autenticazione, limiti, ambiente di test, formato dei dati, webhook e responsabilità. Per dati storici servono mappatura, pulizia, prova di importazione e piano di ritorno.

Test e pubblicazione

I test coprono almeno flussi principali, errori, dispositivi previsti e regressioni critiche. La pubblicazione richiede account intestati correttamente, schede store, informazioni privacy, screenshot e gestione delle osservazioni. Apple spiega quali informazioni dichiarare nella sezione App Privacy. L’approvazione resta una decisione della piattaforma e non può essere garantita dallo sviluppatore.

Privacy e sicurezza stimate dall’inizio

Se l’app tratta dati personali, privacy e sicurezza non sono un testo da aggiungere prima del lancio. L’articolo 25 del Regolamento (UE) 2016/679 richiede protezione dei dati fin dalla progettazione e per impostazione predefinita; l’articolo 32 lega le misure tecniche e organizzative al rischio. Questo si traduce in raccolta minima, ruoli, conservazione, cancellazione, backup e controllo degli accessi.

Il titolare definisce finalità e base giuridica con consulenza adeguata; lo sviluppatore traduce requisiti approvati in comportamento tecnico. Il Garante Privacy raccoglie indicazioni sul principio di privacy by design e by default.

Per la sicurezza mobile, OWASP MASVS offre un riferimento tecnico per archiviazione, crittografia, autenticazione, rete e resilienza. Il livello necessario dipende da dati e rischio: un’app di note locali non ha lo stesso profilo di un prodotto che tratta pagamenti o dati sanitari.

Accessibilità: requisito di prodotto

Contrasto, dimensione dei target, etichette per tecnologie assistive, ordine di lettura e messaggi di errore devono essere presenti nei componenti. Le WCAG 2.2 del W3C forniscono criteri internazionali per contenuti web; le piattaforme mobili aggiungono API e linee guida specifiche.

L’applicabilità degli obblighi dipende da servizio, soggetto ed eventuali esenzioni. Va verificata sul caso concreto. Anche quando non nasce da un obbligo, l’accessibilità riduce barriere e rende i flussi più robusti.

Costo iniziale e costo totale di proprietà

Il preventivo di sviluppo non coincide con il costo dell’intero ciclo di vita. Per confrontare due proposte considera:

Costo totale di proprietà =
sviluppo iniziale
+ servizi e infrastruttura
+ account e licenze
+ manutenzione correttiva
+ aggiornamenti di piattaforma
+ evoluzione del prodotto
+ assistenza e monitoraggio

Non tutte le voci sono prevedibili con precisione, ma devono avere un proprietario. Chiedi chi controlla repository, account store, dominio, cloud, database e servizi esterni. Chiedi come vengono consegnati documentazione, credenziali e backup.

Un contratto chiaro distingue difetto rispetto ai criteri accettati, nuova funzione e cambiamento imposto da un servizio esterno. Specifica durata della garanzia correttiva, livelli di assistenza, finestre di manutenzione e processo per stimare evoluzioni.

Per trasformare queste voci in uno scenario post-lancio separato, usa la guida al costo di manutenzione di un’app. Il budget iniziale e il budget operativo restano così confrontabili, senza sommare attività diverse.

Come confrontare preventivi app

Metti le offerte nella stessa griglia:

• scope incluso e criteri di accettazione;
• piattaforme e versioni supportate;
• backend, pannello web e infrastruttura;
• numero e tipo di integrazioni;
• migrazione dei dati;
• UX/UI e materiali richiesti al cliente;
• test, accessibilità e sicurezza;
• pubblicazione e gestione degli account;
• codice sorgente, documentazione e diritti d’uso;
• manutenzione, tempi di risposta ed esclusioni.

Un prezzo più basso con molte voci «da definire» può diventare meno controllabile. Un prezzo più alto non è automaticamente migliore: deve corrispondere a deliverable e responsabilità verificabili. Chiedi che ogni assunzione importante venga scritta.

Cosa inviare per ricevere una stima utile

1. problema e risultato atteso;
2. tipologie di utenti e relativi permessi;
3. flusso essenziale, dall’ingresso al risultato;
4. dati creati, letti, modificati o cancellati;
5. piattaforme e dispositivi;
6. servizi esterni e referente tecnico;
7. necessità offline, notifiche, pagamenti o geolocalizzazione;
8. materiali già disponibili;
9. data obiettivo e motivo della scadenza;
10. funzioni rinviabili dopo la prima release.

Non serve conoscere la tecnologia. Serve rendere chiaro il processo. Requisiti incerti possono diventare uno spike: un’attività breve per verificare fattibilità prima di impegnare il progetto completo.

Prodotti pubblicati e metodo

Hourly e RouteBudget sono prodotti pubblicati che mostrano lavoro su interfaccia mobile, logica applicativa e rilascio. Non sono modelli da copiare né prove di un risultato commerciale per un altro progetto: servono a verificare che progettazione e delivery arrivino a un prodotto utilizzabile.

Per un’app su misura parto dal flusso, riduco lo scope alla prima versione utile e rendo esplicite dipendenze e criteri di accettazione. Se hai già un brief, posso revisionarlo; se hai solo il processo, possiamo costruire insieme la mappa tecnica.

Domande frequenti