Sviluppo
Come si legge il preventivo di un'app, voce per voce
La domanda arriva quasi sempre nella prima email: quanto costa sviluppare un'app. La risposta onesta è che il numero dipende da decisioni che, nel momento in cui la domanda viene posta, nessuno ha ancora preso. Quello che possiamo fare è spiegare quali sono quelle decisioni e come si legge un preventivo per capire se sta in piedi.
Da che cosa dipende il costo di sviluppo di un'app
Chi chiede un prezzo per un'app ha quasi sempre un'idea precisa del risultato e nessuna idea del perimetro. È normale, ed è anche il motivo per cui la domanda non può ricevere una risposta seria al primo scambio di email. Il perimetro è l'unica cosa che determina davvero il costo.
Un'app che mostra contenuti già pronti e un'app che gestisce account, prenotazioni e abbonamenti sono due mestieri diversi che condividono soltanto l'icona sullo schermo. Nel primo caso il lavoro sta quasi tutto nell'interfaccia. Nel secondo compaiono un server, un database, regole di accesso, e tutti i casi limite che nascono quando due persone toccano lo stesso dato nello stesso istante. Il secondo tipo di app costa un multiplo del primo, a parità di schermate.
Chi risponde con un numero prima di aver chiesto chi sono gli utenti, quali azioni devono poter compiere e con quali sistemi l'app deve parlare sta indovinando. Le due forme che questa risposta assume sono entrambe poco utili: un intervallo così ampio da non permettere nessuna decisione, oppure un prezzo secco costruito su ipotesi che nessuno ha messo per iscritto. La seconda è la peggiore, perché le ipotesi implicite diventano contestazioni a metà progetto.
La domanda da porre è un'altra. Quali funzioni servono perché l'app abbia senso il primo giorno di vita, quanto costa aggiungerne una dopo, e quanto costa tenerla accesa per dodici mesi. Un preventivo che risponde a queste tre cose si può confrontare con un altro. Un numero da solo, no.
Le variabili che spostano davvero il costo di un'applicazione mobile
Queste sono le voci che, nella nostra esperienza, cambiano l'ordine di grandezza di un progetto. Tutto il resto si muove di poco.
Numero e natura delle schermate
Contare le schermate è la stima più grezza, ma è il punto di partenza più onesto. Vale però pesarle: una lista, un dettaglio e un form semplice sono lavoro prevedibile, mentre una schermata con mappa interattiva, editor drag-and-drop e salvataggio automatico vale da sola molte schermate statiche.
Presenza di un backend proprio
Un'app che legge dati pubblici e un'app che ne scrive di propri hanno costi incomparabili. Con un backend arrivano modello dati, regole di sicurezza, backup, ambienti separati per test e produzione, e un pannello per amministrare i contenuti. È spesso la voce più sottovalutata di tutte.
Autenticazione e gestione degli account
Il login non finisce con la schermata di login. Servono recupero password, verifica email, eventuale accesso con Google o Apple, ruoli diversi, e la cancellazione dell'account dall'interno dell'app, che gli store richiedono quando esiste una registrazione. Ognuno di questi pezzi ha i suoi casi limite.
Pagamenti e abbonamenti
Vendere contenuti digitali dentro l'app significa passare dai sistemi di acquisto degli store, con le loro regole e i loro stati. Vendere un servizio erogato fuori dall'app permette circuiti esterni come Stripe. Cambiano l'integrazione, i test e la gestione di rinnovi, rimborsi, cambi di piano e ripristino degli acquisti.
Contenuti da caricare e mantenere
Un archivio di ricette, un listino, un catalogo: il costo va ben oltre la parte tecnica. Qualcuno deve strutturare i dati, normalizzarli, verificarli e caricarli, e poi serve uno strumento per aggiornarli senza toccare il codice. Il ricettario di DietApp supera le quattrocento voci con i valori nutrizionali già calcolati, e quel lavoro esiste a prescindere dall'app.
Integrazioni con sistemi esistenti
Collegarsi a un gestionale, a un sistema di cassa o a un servizio di terzi introduce una dipendenza dalla qualità della documentazione altrui. È la variabile che stimiamo con il margine di errore più alto: prima di quotarla chiediamo sempre accesso alle specifiche e a un ambiente di prova.
Una piattaforma o due
iOS e Android raddoppiano test, dispositivi da provare, pubblicazioni, revisioni e comportamenti specifici da gestire, anche quando la base di codice resta una sola. DietApp è nata solo su Android per questo motivo, con iOS annunciato senza data: una piattaforma sola permette di arrivare sul mercato e imparare, prima di pagare il conto della seconda.
Design su misura o sistema esistente
Partire da componenti standard e da un sistema di stili coerente riduce sensibilmente il tempo di realizzazione. Disegnare ogni schermata da zero, con illustrazioni e animazioni proprie, produce un risultato riconoscibile e costa di più, sia in progettazione sia in sviluppo. È una scelta di posizionamento con effetti diretti sul preventivo.
Nativo o cross-platform: come la scelta tecnica si riflette sul preventivo
La scelta tra sviluppo nativo e cross-platform incide sul preventivo iniziale meno di quanto si creda, e sulla manutenzione molto più di quanto si creda. Con React Native o Flutter una sola base di codice serve entrambe le piattaforme, e questo abbatte il lavoro quando l'obiettivo è essere subito su iOS e Android. Restano fuori i test, che vanno fatti comunque due volte, e le parti che toccano l'hardware, che spesso richiedono codice nativo dedicato.
Il nativo conviene quando l'app vive sul dispositivo: uso intensivo della fotocamera, elaborazione in background, grafica pesante, integrazioni profonde con il sistema operativo. Conviene anche quando una sola piattaforma copre il pubblico reale, perché in quel caso il vantaggio principale del cross-platform sparisce. DietApp è un'app Android nativa proprio per questa ragione.
Esiste una terza strada che quasi nessun preventivo propone, e che a volte è la risposta giusta: rinunciare all'app da store. Una web app progressiva si installa dalla schermata iniziale, si aggiorna quando pubblichiamo una nuova versione e non passa da nessuna revisione. Beachfy e BarbierItalia sono costruite così. Il prezzo di questa scelta è concreto: notifiche meno affidabili su iOS, nessuna presenza nelle ricerche degli store, accesso limitato ad alcune funzioni del telefono. Il vantaggio è altrettanto concreto: nessun tempo di attesa per una correzione urgente e un ciclo di rilascio molto più corto.
Quando un fornitore propone una tecnologia senza spiegare cosa ci si perde, il preventivo è già incompleto. La domanda utile da fare è quali funzioni della lista richiedono codice nativo, perché quelle sono le righe che possono far saltare la stima.
I costi ricorrenti che quasi nessun preventivo app mette per iscritto
Il prezzo di sviluppo è una spesa singola. Un'app pubblicata è un impegno che continua, e queste voci si presentano ogni anno.
Account sviluppatore degli store
Apple richiede una quota di iscrizione annuale, Google Play una quota una tantum per l'account. Sono cifre pubbliche e modeste rispetto al progetto, ma la quota Apple va rinnovata: se scade, l'app sparisce dallo store. Va messa in calendario come qualsiasi altra scadenza.
Infrastruttura e database
Hosting, autenticazione, database, archiviazione delle immagini e traffico si pagano a consumo. Il costo cresce con il numero di utenti e con quanto spesso l'app legge e scrive, mentre il numero di schermate incide poco. Un modello dati scritto male si paga ogni mese, e il conto arriva quando il prodotto inizia a funzionare.
Servizi di terze parti a consumo
I modelli di intelligenza artificiale si pagano a token, l'invio delle email transazionali a messaggio, gli SMS a invio, alcune mappe a chiamata. Una funzione basata sull'IA ha un costo marginale per ogni singolo utilizzo. Se il prezzo dell'abbonamento non lo copre, l'app perde denaro proprio quando viene usata di più.
Manutenzione e aggiornamenti obbligatori
Ogni anno escono nuove versioni di iOS e Android, e Google Play impone un livello minimo di API per restare pubblicabili. Cambiano le regole sulla privacy, si deprecano librerie, si rompono integrazioni. Un'app lasciata ferma invecchia comunque: dopo qualche stagione smette semplicemente di poter essere aggiornata.
Assistenza agli utenti
Recensioni a cui rispondere, email di chi non riesce ad accedere, richieste di cancellazione dei dati previste dal GDPR, segnalazioni di malfunzionamenti da riprodurre. Sono ore di lavoro di qualcuno, e va deciso in anticipo chi lo fa: il cliente, chi ha sviluppato l'app, o nessuno.
Come costruire un preventivo per un'app in quattro passaggi
Questo è il percorso che seguiamo prima di scrivere qualsiasi cifra, e che consigliamo di chiedere a chiunque altro.
- 01
Scrivere le azioni, non le funzioni
Al posto di un generico sistema di prenotazione, una frase per ogni azione reale: il cliente sceglie l'ombrellone sulla piantina, indica i giorni, riceve un codice con il biglietto digitale. Le azioni si contano, si stimano e si tagliano. Le funzioni descritte a parole generiche no.
- 02
Separare il primo rilascio da tutto il resto
Sulla lista delle azioni serve una riga di taglio: cosa deve esistere il giorno uno perché qualcuno usi il prodotto. Quello che sta sotto la riga non sparisce, viene quotato a parte. Questo passaggio da solo cambia l'ordine di grandezza del progetto e permette di verificare l'idea prima di spendere tutto.
- 03
Far quotare a voci, con le ipotesi scritte
Ogni voce deve dire cosa include e cosa esclude. Se la stima presuppone che i contenuti arrivino già strutturati, che il design venga fornito, o che un servizio esterno abbia una documentazione utilizzabile, va scritto. Le ipotesi non dichiarate sono la causa più frequente delle rinegoziazioni.
- 04
Aggiungere la riga dei dodici mesi successivi
Sotto il totale di sviluppo va una seconda somma: account sviluppatore, infrastruttura, servizi a consumo, manutenzione, assistenza. Due preventivi vanno confrontati su questo totale. Capita spesso che l'offerta più bassa sullo sviluppo sia la più cara sul primo anno, perché scarica sul cliente tutto ciò che viene dopo.
Cosa deve contenere un preventivo serio per sviluppare app iOS e Android
Se una di queste voci manca, la domanda va fatta prima di firmare.
| Voce | Perché serve |
|---|---|
| Elenco delle schermate con i relativi stati | Distingue la schermata piena da quella vuota, in caricamento o in errore, che è dove si nasconde metà del lavoro reale. |
| Ipotesi esplicite della stima | Rende verificabile il prezzo e impedisce che una condizione data per scontata diventi una variazione a pagamento. |
| Perimetro escluso | Dichiarare cosa non è compreso vale quanto dichiarare cosa lo è, e chiude in anticipo le discussioni sul non detto. |
| Piattaforme e versioni minime supportate | Supportare sistemi operativi molto vecchi allunga i test e limita le librerie utilizzabili, con effetti diretti sul costo. |
| Proprietà del codice e degli account | Chiarisce a chi restano il repository, l'account sviluppatore e il progetto di backend il giorno in cui il rapporto finisce. |
| Tempi con le dipendenze dal cliente | Le consegne di contenuti, credenziali e approvazioni sono spesso la causa reale dei ritardi, e vanno messe a calendario. |
| Stima dei costi ricorrenti del primo anno | Permette di confrontare offerte diverse sul costo totale del primo anno, oltre che sulla cifra iniziale di sviluppo. |
| Cosa succede dopo il rilascio | Separa la correzione dei difetti, che è dovuta, dalla manutenzione evolutiva, che è un contratto a parte. |
| Gestione della pubblicazione sugli store | Preparazione delle schede, revisioni, eventuali rifiuti e ripubblicazioni sono lavoro concreto da mettere a preventivo. |
Due prodotti con abbonamenti reali: DietApp e BarbierItalia
Parliamo di costi con più tranquillità da quando paghiamo anche i nostri. DietApp e BarbierItalia sono prodotti dello studio, sviluppati e mantenuti a nostre spese, e ogni voce di questo articolo la vediamo arrivare in fattura.
DietApp è pubblicata su Google Play dal settembre 2025 e ha superato i cinquecento download. È freemium, con Premium a 6,99 euro al mese o 34,99 euro all'anno, gestito tramite gli acquisti di Google Play e RevenueCat. La parte interessante dal punto di vista economico è che le funzioni principali costano a ogni utilizzo: generare un piano alimentare, rispondere in chat con l'assistente Bianca, stimare calorie e macronutrienti dalla foto di un piatto sono tutte chiamate a un modello che si paga a consumo. Un utente molto attivo costa più di un utente occasionale. Il prezzo dell'abbonamento deve stare sopra il costo medio per utente prima ancora di guardare il mercato, altrimenti il successo del prodotto diventa un problema di cassa. La scheda del progetto è nella sezione progetti del sito, il prodotto vive su diet-app.it.
BarbierItalia funziona con una logica opposta e altrettanto istruttiva. Il canone è fisso, 29 euro al mese o 249 euro all'anno, con zero commissioni sulle prenotazioni e trenta giorni di prova senza carta, e i pagamenti passano da Stripe. Ogni salone abbonato riceve un sito su un proprio sottodominio e un pannello di gestione. Qui il vincolo è che il costo di infrastruttura per singolo salone, insieme al tempo di assistenza, deve restare stabilmente sotto il canone, altrimenti la crescita erode il margine invece di costruirlo.
C'è poi il caso di Beachfy, ancora in pre-lancio con apertura dichiarata per l'estate 2027 e attivazione gratuita per i gestori. L'applicativo è sviluppato, l'infrastruttura è accesa e i costi corrono da prima del primo euro incassato. È la situazione in cui si trova qualsiasi app appena pubblicata, ed è la ragione per cui il modello economico va disegnato insieme al preventivo, non dopo il rilascio.
Domande frequenti sul costo di sviluppo di un'app
Una media non esiste, e chi la fornisce sta mettendo insieme progetti che non hanno nulla in comune. Il costo dipende dal numero di azioni che l'utente può compiere, dalla presenza di un backend, dagli account, dai pagamenti e dalle integrazioni. Con la lista delle azioni in mano una stima diventa possibile in pochi giorni; senza, qualsiasi cifra è un'ipotesi.
Quasi sempre perché descrivono progetti diversi con lo stesso nome. Uno include il pannello di amministrazione, i test su più dispositivi, la pubblicazione sugli store e la correzione dei difetti dopo il rilascio; l'altro no. Il confronto ha senso solo dopo aver riportato le due offerte sulla stessa lista di voci.
Nella maggior parte dei casi sì, a condizione che la versione ridotta risolva davvero un problema. Un'app dimezzata a caso non insegna niente. Una prima versione che copre bene un percorso completo permette di capire come si comportano gli utenti reali e di decidere le funzioni successive con dati invece che con opinioni.
L'account sviluppatore Apple con rinnovo annuale, l'infrastruttura e il database a consumo, gli eventuali servizi di terze parti a chiamata, gli aggiornamenti tecnici necessari per restare conformi alle regole degli store e l'assistenza agli utenti. Queste voci si presentano anche quando non si aggiunge nessuna funzione nuova.
Serve almeno una distinzione chiara delle voci. Anche con una tecnologia cross-platform, la seconda piattaforma porta con sé test aggiuntivi, dispositivi diversi, una pubblicazione separata e alcune parti scritte in codice nativo. Un preventivo che tratta le due piattaforme come un blocco unico e indivisibile nasconde un rischio di stima.