Quanto tempo ci vuole a costruire un'app mobile? La risposta onesta

A marzo di quest'anno, un titolare di un'officina meccanica di Taranto mi ha contattato per chiedermi se potevamo sviluppare un'app mobile per la gestione degli appuntamenti e la comunicazione con i clienti. Era entusiasta, aveva già un'idea chiara di quello che voleva, e la prima domanda che mi ha fatto è stata: "In quanto tempo possiamo averla?". Gli ho risposto quello che rispondo sempre in questi casi: DIPENDE. E non è un modo per evitare la risposta, è proprio la risposta vera, quella che merita una spiegazione articolata.

La domanda "quanto tempo ci vuole" nasconde in realtà tre domande diverse, e rispondere senza distinguerle significa dare una stima che nella maggior parte dei casi risulterà sbagliata, per difetto o per eccesso. Le tre domande sono: quanto tempo ci vuole per costruirla, quanto tempo ci vuole per pubblicarla, e quanto tempo ci vuole perché funzioni nel modo in cui l'hai immaginata. Ognuna di queste ha una risposta diversa, e tutte e tre contribuiscono al tempo complessivo del progetto.

In questo articolo vado a rispondere a queste domande in modo onesto, basandomi sui progetti che ho seguito negli ultimi anni, senza promesse irrealistiche e senza spaventarti inutilmente.

Prima di tutto: che tipo di app stai pensando?

La risposta al "quanto tempo" dipende in modo diretto dal tipo di app che vuoi costruire. Non tutte le app sono uguali, e nel 2026 un imprenditore ha a disposizione tre strade principali, ciascuna con tempi e complessità radicalmente diversi.

La prima strada è la Progressive Web App (PWA): un sito web che si comporta come un'app, si installa sullo smartphone senza passare dall'App Store, e può inviare notifiche push. Ho scritto una guida dettagliata sulle PWA specificamente per le PMI in questo articolo, ma in sintesi è la soluzione più rapida da costruire quando i requisiti sono relativamente semplici e non è necessaria un'integrazione profonda con le funzionalità hardware del dispositivo.

La seconda strada è l'app cross-platform sviluppata con framework come Flutter (che uso spesso nei miei progetti) o React Native. Un singolo codebase, pubblicata sia su iOS che su Android. È la scelta che bilancia meglio tempi e qualità per la maggior parte delle PMI, dal momento che evita di dover costruire e mantenere due applicazioni distinte.

La terza strada è l'app nativa, sviluppata separatamente per iOS (in Swift) e per Android (in Kotlin). È la soluzione con le migliori prestazioni teoriche possibili, ma anche la più lunga in termini di sviluppo, e nella maggior parte dei casi per una PMI non giustifica l'investimento aggiuntivo rispetto alla cross-platform, seppur ci siano situazioni specifiche in cui è la scelta giusta.

Questa distinzione è il primo fattore che definisce i tempi. Se non l'hai ancora fatta con il tuo sviluppatore, il progetto non è ancora pronto per avere una stima realistica.

Le fasi di sviluppo di un'app: dove va davvero il tempo

Indipendentemente dal tipo di app, ogni progetto attraversa delle fasi ben definite. Conoscerle ti aiuta a capire dove va il tempo e perché certi rallentamenti non dipendono necessariamente dallo sviluppatore.

La prima fase è quella di analisi e definizione dei requisiti. Prima di scrivere una riga di codice, bisogna capire esattamente cosa deve fare l'app, chi la usa, come si muove l'utente al suo interno, e quali dati deve gestire. Questa fase dura tipicamente da una a tre settimane, a seconda della complessità del progetto e della chiarezza delle idee di partenza. Una delle cose che ho imparato nei progetti che seguo è che questa fase non si può tagliare: ogni ora investita qui risparmia giorni di sviluppo in seguito, proprio perché le modifiche in corso d'opera costano molto di più di quelle fatte sulla carta.

La seconda fase è il design dell'interfaccia. Prima di programmare, si definisce come appare e come funziona l'app visivamente: la struttura delle schermate, il flusso di navigazione, i colori e i componenti. Questa fase è spesso sottovalutata dai clienti, ma è qui che si prendono le decisioni più importanti sull'esperienza dell'utente. Può durare da due settimane a un mese, a seconda di quante revisioni sono necessarie.

La terza fase è lo sviluppo vero e proprio, ossia quella a cui tutti pensano quando chiedono "quanto ci vuole", ma che di fatto è soltanto una parte del lavoro totale. Per un'app con funzionalità di base (login, profilo utente, due o tre sezioni principali, notifiche push), lo sviluppo cross-platform con Flutter richiede tipicamente tra le sei e le dieci settimane. Per un'app più complessa, che prevede integrazioni con sistemi gestionali esistenti, pagamenti, geolocalizzazione, o logiche di prenotazione avanzate, si va facilmente a tre o quattro mesi di solo sviluppo.

La quarta fase è il testing. Un'app che non è stata testata a fondo non è pronta per essere pubblicata, e non soltanto per ragioni tecniche: Apple e Google verificano attivamente il comportamento dell'app durante la revisione, e un bug evidente è motivo di rifiuto. Questa fase dura di solito una o due settimane, durante le quali emergono inevitabilmente alcuni problemi da correggere prima di procedere.

Il collo di bottiglia che nessuno calcola: la revisione degli store

C'è un passaggio del percorso che molti clienti non conoscono e che può spostare la data di lancio di settimane intere: la revisione delle app da parte di Apple e Google.

Quando un'app è pronta tecnicamente, non puoi semplicemente pubblicarla su App Store o Google Play nel giro di poche ore. Apple in particolare ha un processo di revisione manuale che può richiedere da 24 ore fino a due settimane, a seconda del tipo di app, del periodo dell'anno (in prossimità delle ferie i tempi si allungano) e di eventuali richieste di chiarimento. Google è generalmente più rapido, ma anch'esso ha tempi di revisione che variano e che non sono sotto il controllo dello sviluppatore.

Se la prima submission viene rifiutata, cosa che succede con una certa frequenza specialmente alla prima pubblicazione di un account nuovo, si apre un ciclo di modifiche e nuove submission che può facilmente aggiungere due o tre settimane al progetto. Proprio per questo, nei progetti che seguo, inizio la preparazione dei materiali per gli store (screenshot in tutti i formati richiesti, descrizioni, icone nelle dimensioni corrette, informativa sulla privacy) in parallelo allo sviluppo, non dopo.

Stima realistica per tipo di progetto

Senza entrare in cifre specifiche, posso darti degli ordini di grandezza basati sulla mia esperienza diretta.

Un'app semplice, con funzionalità di base e senza integrazioni complesse con sistemi esterni, richiede solitamente tra due e quattro mesi dall'avvio del progetto alla pubblicazione. Questo intervallo comprende analisi, design, sviluppo, testing e revisione degli store.

Un'app di complessità media, come quella dell'officina di Taranto con cui ho aperto questo articolo, che gestisce appuntamenti, invia notifiche, mantiene uno storico dei clienti e si integra con un sistema di comunicazione, si attesta più spesso tra i quattro e i sei mesi.

Un'app complessa, che prevede pagamenti online, geolocalizzazione, dashboard di gestione per gli operatori, ruoli utente differenziati o integrazioni con software gestionali preesistenti, può tranquillamente richiedere sei mesi o più. In questi casi la complessità non è tanto nello sviluppo in sé, quanto nella definizione dei requisiti e nelle integrazioni con sistemi terzi che non sempre offrono API ben documentate.

Cosa rallenta un progetto app, e dipende spesso da te

Nei progetti che ho seguito, ho notato che i ritardi più frequenti non vengono quasi mai dalla parte tecnica. Vengono da dinamiche che dipendono dal cliente, e che vale la pena conoscere in anticipo per gestirle meglio.

Il primo fattore è la lentezza nel feedback. Lo sviluppo di un'app è un processo iterativo: lo sviluppatore mostra una schermata o una funzionalità, tu la vedi, dai il tuo parere, si procede. Se il feedback arriva con settimane di ritardo perché non c'è tempo di guardare, o perché la persona che deve approvare è sempre in trasferta, l'intero progetto si allunga di conseguenza. Dal momento che questo è uno dei rallentamenti più comuni che ho visto, il consiglio che do sempre è di bloccare in agenda una revisione settimanale con lo sviluppatore, anche breve, fin dall'inizio del progetto.

Il secondo fattore è il cambiamento dei requisiti in corso d'opera. Aggiungere funzionalità a metà sviluppo non è impossibile, ma ogni aggiunta significativa ha un costo in termini di tempo che spesso non è proporzionale alla dimensione apparente della modifica. Aggiungere un sistema di messaggistica interna a un'app già a metà sviluppo, per esempio, può richiedere di rivedere l'architettura dei dati, non soltanto di aggiungere una schermata.

Il terzo fattore, che ho incontrato spesso in PMI che hanno già un software gestionale in uso, è la difficoltà di accesso alle API o ai dati del sistema esistente. Se la tua nuova app deve integrarsi con il gestionale che usi in azienda, e il fornitore di quel gestionale impiega settimane a fornirti le credenziali di accesso o la documentazione tecnica, quel tempo si aggiunge inevitabilmente al progetto. Chiedere questa documentazione nelle prime settimane del progetto, non quando ne hai bisogno, è una delle cose che fa la differenza tra un progetto che rispetta i tempi e uno che li sfora.

Come capire se la stima che hai ricevuto è realistica

Quando ricevi una proposta per lo sviluppo di un'app, ci sono alcune domande che puoi fare per capire se la stima è seria o è stata costruita senza un'analisi reale del progetto.

Chiedi come è articolata la stima: quante settimane per ogni fase. Una risposta vaga del tipo "la facciamo in due mesi" senza dettaglio sulle fasi è quasi sempre un segnale di stima formulata senza un'analisi approfondita dei requisiti.

Chiedi cosa è incluso e cosa no: il design è incluso? Il testing? La pubblicazione sugli store? La gestione di eventuali rifiuti durante la revisione Apple? Questi sono tutti elementi che aggiungono tempo e che devono essere esplicitamente inclusi o esclusi nella proposta, non dati per scontati.

Chiedi cosa succede se cambiano i requisiti: un contratto ben strutturato distingue tra le funzionalità iniziali concordate e le eventuali aggiunte successive, con un meccanismo chiaro per gestire quest'ultime in termini di tempi e costi aggiuntivi.

Qual è dunque la risposta?

Per tornare all'officina di Taranto: abbiamo avviato il progetto a marzo, completato l'analisi e il design entro aprile, terminato lo sviluppo principale a fine maggio, superato la revisione Apple al primo tentativo, e l'app è attiva dal giugno scorso. Quattro mesi in totale, in linea con la stima iniziale.

La risposta alla domanda "quanto tempo ci vuole per costruire un'app mobile" è dunque questa: per un'app di complessità media, pensata per una PMI con requisiti definiti, pianifica tra i tre e i cinque mesi dall'avvio del progetto alla pubblicazione sugli store. Non meno, a meno che la soluzione giusta per il tuo caso non sia una PWA o che le funzionalità siano davvero minime. Non molto di più, se il processo è gestito in modo strutturato, i feedback arrivano in tempo e i requisiti non cambiano in corso d'opera.

Se stai valutando se sviluppare un'app per la tua attività e vuoi capire quale tipo di soluzione ha senso nel tuo caso specifico, puoi contattarmi direttamente. Nella maggior parte dei casi, venti minuti di chiamata sono sufficienti per chiarire il quadro e darti una stima realistica.