Un'app non finisce di costare al lancio. Aggiornamenti OS, sicurezza, hosting, canone store: i costi ricorrenti che trasformano una release in un ciclo di vita. Ti mostriamo come budgettare anni di manutenzione senza sorprese, quando conviene riscrivere, e come riconoscere il debito tecnico prima che diventi ingestibile.
Una app sostenibile non si misura solo al giorno della release. Pianifica aggiornamenti, monitoraggio e spazio per il debito tecnico come parte del prodotto, così ogni nuova versione resta affidabile senza trasformare la manutenzione in emergenza.
Molti committenti vedono il lancio dell'app come la fine del progetto. In realtà è l'inizio di una maratona. Ecco perché:
Apple e Google rilasciano nuove versioni di iOS e Android ogni anno. Non è opzionale aggiornarsi. Un'app che non segue gli aggiornamenti del sistema operativo perde accesso alle nuove API, alle features di sicurezza, e infine viene rimossa dagli store. Ogni aggiornamento richiede testing completo e spesso modifiche al codice.
Le librerie che usi (SDK, package npm, framework) ricevono aggiornamenti di sicurezza costanti. Un'app che non aggiorna le dipendenze è un bersaglio per hacker. Non è questione di "se" avrai una vulnerabilità, ma "quando".
Ogni anno escono nuovi modelli di smartphone con dimensioni diverse, densità di pixel diverse, notch e fotocamere posizionate diversamente. La tua UI deve adattarsi senza rompere l'esperienza utente.
Quello che era innovativo nel 2024 è standard nel 2026. Se i competitor hanno dark mode, live notifications, offline mode, i tuoi utenti li pretendono. Questi non sono lussi, sono baseline.
App Store e Google Play cambiano le policy di submission ogni anno. La gestione della privacy, il tracciamento, i permessi: tutto evolve. L'app deve conformarsi per restare disponibile.
Il costo totale di proprietà non ha una cifra uguale per tutte le app. Prima separa il compenso di sviluppo dai costi esterni e dal lavoro post-lancio.
Una PWA o un'app con contenuti locali può non avere un backend significativo. Login, database, file, notifiche e sincronizzazione aggiungono invece servizi cloud. Il costo dipende da utenti, richieste, storage e traffico: può partire da pochi euro e arrivare a centinaia per prodotti più utilizzati. Chiedi sempre quali quote sono incluse e cosa succede quando vengono superate.
Per distribuire su App Store, l'Apple Developer Program costa 99 USD per anno di iscrizione, in valuta locale dove prevista (fonte Apple). Google Play richiede una quota di registrazione una tantum di 25 USD (fonte Google). Sono costi dell'account, separati dal lavoro di pubblicazione.
Crash reporting, logging, backup, aggiornamento delle dipendenze e test su dispositivi reali possono usare piani gratuiti, canoni o consumo a volume. Non assegnare una cifra standard: indica strumenti, quote, frequenza e responsabile. TLS e CDN possono essere inclusi nel provider oppure richiedere una configurazione separata.
Un bug è un comportamento che non rispetta il perimetro approvato. Una nuova funzione amplia quel perimetro. Il contratto deve distinguere copertura, priorità, tempi di risposta e modalità di quotazione. Nei progetti Contat, i primi 12 mesi hanno copertura e perimetro definiti nel capitolato; dal tredicesimo mese il riferimento ordinario è una manutenzione annuale pari a circa il 10-20% del costo di sviluppo, in base alla tecnologia e al carico.
Firebase Cloud Messaging, analytics e crash reporting possono avere componenti senza costo e componenti a consumo. Pagamenti, SMS, mappe, email, AI e altri servizi hanno condizioni proprie: vanno elencati come costi esterni e non nascosti dentro una voce generica di manutenzione.
Usa questa tabella come orientamento, non come listino automatico:
| Voce | Frequenza | Come stimarla | Nota |
|---|---|---|---|
| Manutenzione e compatibilità | Annuale | PWA ~10%; Flutter ~15%; nativa ~20% del costo di sviluppo | Orientamento dopo il primo anno |
| Cloud, backend e storage | Mensile | Consumo e quote del provider | Da pochi euro a centinaia secondo traffico e dati |
| Account store | Annuale / una tantum | Apple 99 USD/anno; Google 25 USD una tantum | Importi indicati dai provider |
| Monitoraggio e crash reporting | Mensile | Piano e volume d'uso | Spesso esistono quote senza costo |
| QA e pubblicazione | Per release | Ore e dispositivi coperti | Da includere nel piano o quotare |
| Nuove funzioni e redesign | Quando richiesti | Nuovo preventivo | Non confonderli con bugfix |
Non esiste un totale annuale tipico valido per ogni app. Per un primo scenario usa il costo di sviluppo approvato e applica la percentuale della tecnologia; aggiungi poi cloud, store e servizi esterni in base all'uso reale.
Parti dal preventivo approvato, non da un totale generico trovato online.
La guida sui costi di sviluppo indica PWA da 2.000 €, MVP Flutter tra 5.000 € e 15.000 €, app native tra 15.000 € e 40.000 € o più. Sono fasce di orientamento. Il tuo contratto resta la base effettiva.
Come esempio matematico, una manutenzione annuale del 10% su una PWA da 2.000 € vale circa 200 €. Su un MVP Flutter da 5.000 € a 15.000 €, il 15% vale circa 750-2.250 €. Su un'app nativa da 15.000 € a 40.000 €, il 20% vale circa 3.000-8.000 €. Sono scenari indicativi, non previsioni né prezzi automatici.
Somma cloud, database, storage, email, mappe, pagamenti, account store e strumenti di monitoraggio. Separali dal lavoro del team e verifica le quote ogni volta che crescono utenti o traffico.
Compatibilità, sicurezza e bug restano nel piano concordato. Nuove funzioni, redesign, migrazioni e riscritture sono nuovi lavori: richiedono analisi e preventivo dedicati.
Controlla crash, incidenti, dipendenze, tempi di rilascio, costi cloud e richieste degli utenti. Aggiorna il budget sulla base dei dati raccolti, non di una percentuale applicata senza contesto.
Il debito tecnico si misura con segnali osservabili: bug ricorrenti, aggiornamenti sempre più lenti, dipendenze non supportate, crash, perdita di dati o impossibilità di modificare una funzione senza rompere le altre.
Mantieni quando il codice è comprensibile, gli incidenti sono gestibili e il team può ancora rilasciare in modo regolare.
Rifattorizza quando il problema è circoscritto: aggiorna una dipendenza, copri un modulo con test o sostituisci una parte fragile senza cambiare tutto il prodotto.
Valuta una riscrittura quando architettura, dati o dipendenze impediscono di sostenere il prodotto. Una riscrittura non ha un prezzo standard: è un nuovo progetto e va stimata dopo un audit, con lo stesso metodo usato per un'app nuova. Nel frattempo definisci come tenere sicura e disponibile la versione esistente.
Esistono strategie concrete per mantenere un'app senza spendere una fortuna:
Test manuali su 50 device costano. Test automatici no. Se investi 2-3 settimane per scrivere unit test e integration test, risparmi 100+ ore di QA manuale ogni anno. ROI positivo subito.
GitHub Actions, GitLab CI, FastLane: automatizzate build, test, deploy. Riduce errori e velocizza il ciclo release. La maggior parte dei servizi ha tier gratuito fino a certi limiti.
Tools come Dependabot (GitHub) o Snyk avvisano automaticamente quando una libreria ha vulnerabilità. Non aspettare il breach; fix preventivo costa meno.
Se il backend è sovradimensionato per quello che serve, migra a serverless (AWS Lambda, Google Cloud Functions) invece di VM dedicata. Paghi solo per quello che usi, e lo scaling è automatico.
Se mantieni sia iOS che Android nativi, duplichi il lavoro. React Native, Flutter, o Kotlin Multiplatform condividono logica e riducono il team size di un 30-50%.
Non aggiornare il framework ogni volta che esce una versione. Aggiorna ogni 12-18 mesi, skipping patch release minori. Risparmia weeks di lavoro e testing.
Il costo più alto di un'app non è lo sviluppo iniziale. È il costo di mantenerla vivente mentre il mondo (iOS, Android, user expectations) continua a evolversi.
Approfondisci i temi di questo articolo:
Impara a budgettare la manutenzione nel tempo, riconoscere il debito tecnico, e scegliere tra manutenzione continua e riscrittura.