Costo manutenzione app: formula, attività e budget annuale

Tre esempi di budget annuale (non prezzi medi di mercato)

Sono ipotesi didattiche per mostrare la formula, non prezzi medi di mercato, piani consigliati, preventivi o risultati di clienti. Le ore indicate sono mensili nell’ordine: correttive + evolutive + QA/release. IVA, commissioni degli Store ed emergenze restano escluse.

1. Scenario essenziale: (2 + 3 + 2) ore × 50 €/ora = 350 €/mese. Riserva 10%: 35 €/mese. Con 600 € di servizi annuali, (350 € + 35 €) × 12 + 600 € = 5.220 €/anno.
2. Scenario con evoluzione continua: (4 + 8 + 3) ore × 65 €/ora = 975 €/mese. Riserva 15%: 146,25 €/mese. Con 1.800 € di servizi, (975 € + 146,25 €) × 12 + 1.800 € = 15.255 €/anno.
3. Scenario con più piattaforme e release frequenti: (8 + 16 + 6) ore × 80 €/ora = 2.400 €/mese. Riserva 20%: 480 €/mese. Con 4.800 € di servizi, (2.400 € + 480 €) × 12 + 4.800 € = 39.360 €/anno.

Per costruire il tuo scenario, sostituisci ore, tariffa, riserva e servizi con dati contrattuali. Una nuova funzione ampia o un incidente urgente va stimato separatamente se non rientra nel perimetro.

Manutenzione non significa «tenere l’app online»

Un’app è parte di un sistema vivo: codice mobile, backend, database, servizi esterni, account store, certificati e dispositivi degli utenti. Anche senza nuove funzioni, sistemi operativi, SDK, policy, API e librerie cambiano. La manutenzione governa questo cambiamento prima che diventi un blocco.

Conviene distinguere quattro categorie:

• correttiva: ripristina un comportamento che non rispetta requisiti approvati;
• adattiva: adegua l’app a nuove versioni di sistema, API, dispositivi, regole o servizi;
• evolutiva: modifica o aggiunge comportamento per un bisogno di prodotto;
• preventiva: riduce rischio futuro tramite aggiornamenti, test, osservabilità, documentazione e rimozione di dipendenze fragili.

Possono comparire nello stesso rilascio, ma devono restare riconoscibili nel report. Se tutto viene chiamato «assistenza», il cliente non sa se paga una correzione, una nuova funzione o un adeguamento imposto dall’ecosistema.

Cosa compone il costo mensile

Triage e manutenzione correttiva

Una segnalazione utile va riprodotta con versione dell’app, dispositivo, sistema, account, rete e passaggi. Il triage determina impatto, origine e priorità. Non ogni errore visibile nasce nell’app: un’API indisponibile, dati incoerenti, credenziali scadute o una configurazione remota possono produrre lo stesso sintomo.

Il budget correttivo copre analisi, correzione, revisione e test. Una finestra di garanzia dopo la consegna può includere difetti rispetto ai criteri accettati, ma non equivale a manutenzione illimitata. Contratto e verbale di accettazione devono definire durata, perimetro e procedura.

Adeguamenti a sistemi, store e API

iOS, Android e servizi esterni introducono versioni, deprecazioni e requisiti. Un adeguamento può toccare permessi, notifiche, login, pagamenti, attività in background, privacy manifest o strumenti di compilazione. Anche un backend invariato può dover accettare più versioni dell’app durante l’aggiornamento degli utenti.

Apple raccoglie in App Store Connect le attività per mantenere e aggiornare un’app. Google pubblica i requisiti sul target API level. Alla revisione del 21/08/2026, Google richiede dal 31/08/2026 Android 16/API 36 per nuove app e aggiornamenti standard. Wear OS e Android Automotive richiedono API 35; Android TV e Android XR API 34. Le app esistenti standard devono raggiungere API 35 per restare disponibili ai nuovi utenti su dispositivi con una versione Android superiore al target dell’app. È prevista la possibilità di richiedere un’estensione fino al 01/11/2026. Sono requisiti temporali: controlla sempre la pagina ufficiale prima di pianificare una release.

Evoluzione controllata

Piccole evoluzioni possono entrare in un monte ore: modifica di un flusso, nuovo campo, regola di validazione o miglioramento basato su feedback. Ogni richiesta deve avere descrizione, criterio di accettazione, stima e priorità. Se tocca architettura, dati o più piattaforme, non è più una «piccola modifica» anche se la modifica visibile sembra minima.

Separare ore evolutive da correttive permette di leggere la salute del prodotto. Se il correttivo assorbe il budget, aggiungere funzioni aumenta il debito tecnico. Se non emergono difetti ma il prodotto deve crescere, il budget può seguire la roadmap.

QA, build e release

Una modifica non termina quando funziona sul dispositivo dello sviluppatore. Servono revisione, build riproducibile, test dei flussi critici, note di rilascio, eventuale aggiornamento delle schede privacy e invio agli store. Apple descrive come preparare e inviare una nuova versione e applica le proprie App Review Guidelines.

Il budget QA/release dipende dalla matrice e dal rischio. Login, acquisti, sincronizzazione, notifiche e cancellazione account meritano regressione anche quando la modifica sembra lontana. Automatizzare controlli ripetitivi aiuta, ma non elimina prove su dispositivi e condizioni reali.

Costi annuali e servizi esterni

Oltre al lavoro, elenca ogni servizio con intestatario, piano, scadenza e pagamento:

• account developer e distribuzione;
• hosting, database, storage e traffico;
• email, SMS, mappe, pagamenti e notifiche;
• monitoraggio errori, log e analytics;
• dominio, certificati e DNS;
• repository, CI/CD e distribuzione delle build;
• backup, archiviazione e ripristino;
• licenze per componenti, font o strumenti.

Non sommare soltanto il prezzo corrente. Registra soglie d’uso, valuta, IVA, rinnovo e conseguenze del mancato pagamento. Un servizio gratuito può avere limiti rilevanti con l’uso; uno a consumo richiede allarmi e tetti di spesa.

Gli account operativi devono appartenere all’organizzazione, non restare legati a un indirizzo personale dello sviluppatore. Usa ruoli nominativi, autenticazione forte e procedura di revoca. La continuità operativa costa meno quando la proprietà degli account e la documentazione sono ordinate.

Costruire scenari, non percentuali

La percentuale sul costo iniziale è una scorciatoia che nasconde differenze. Un’app locale con poche dipendenze ha un profilo diverso da un prodotto con account, backend, pagamenti, dati sincronizzati e due store. Qualità del codice, test e documentazione cambiano il lavoro necessario.

Costruisci almeno tre scenari con la stessa formula:

1. base: monitoraggio, correzioni limitate, aggiornamenti pianificati e una finestra di release;
2. operativo: ore ricorrenti per supporto, piccoli miglioramenti e release regolari;
3. critico: tempi di risposta più stretti, ambienti separati, test più ampi e riserva maggiore.

Non attribuire probabilità false. Scrivi condizioni che attivano lo scenario: piattaforme, orari, dipendenze, utenti, dati sensibili o penali. Il calcolatore permette di sostituire ipotesi quando arrivano dati reali.

SLA: presa in carico non significa soluzione

Un Service Level Agreement utile definisce severità, orario, canale, tempo di risposta e processo di aggiornamento. Deve distinguere:

• presa in carico: conferma e classificazione;
• diagnosi: raccolta di evidenze e causa probabile;
• mitigazione: intervento per ridurre l’impatto;
• correzione: modifica verificata e distribuita;
• ripristino: ritorno misurabile al servizio previsto.

Promettere una soluzione entro un tempo fisso è rischioso quando dipende da revisione degli store, provider esterno o disponibilità di dati. Un accordo serio indica dipendenze ed esclusioni, senza confondere rapidità di comunicazione con controllo completo.

La severità si basa sull’impatto: servizio bloccato, funzione critica degradata, problema circoscritto o difetto cosmetico. Chi segnala fornisce evidenze; chi gestisce mantiene cronologia, decisioni e aggiornamenti.

Monitoraggio, backup e ripristino

Senza osservabilità, la manutenzione comincia dalla segnalazione dell’utente e perde contesto. Configura eventi tecnici, crash reporting, log del backend e allarmi sulle funzioni critiche. Raccogli soltanto i dati strettamente necessari, limita gli accessi e i tempi di conservazione, e non inserire dati personali o secret nei log.

Un backup non è una strategia finché non viene provato il ripristino. Definisci frequenza, conservazione, cifratura, ubicazione e responsabile. Testa il recupero in un ambiente isolato e registra tempo e risultato. Per modifiche allo schema prepara migrazione, verifica e rollback.

Monitoraggio e backup non sono visibili nell’interfaccia, ma riducono i tempi di diagnosi e il rischio di perdita. Vanno preventivati come parte del servizio, non aggiunti dopo un incidente.

Sicurezza e dipendenze

Le librerie velocizzano lo sviluppo ma introducono versioni, vulnerabilità e compatibilità. Un aggiornamento massivo e tardivo è più rischioso di piccoli passaggi verificati. Mantieni inventario, controlla release note, rimuovi pacchetti inutilizzati e pianifica test dopo ogni aggiornamento rilevante.

OWASP MASVS offre un riferimento tecnico per archiviazione, crittografia, autenticazione, rete e interazione con la piattaforma. Non sostituisce una valutazione del rischio: aiuta a rendere i controlli verificabili. Prodotti che trattano pagamenti, dati sanitari o informazioni riservate richiedono profondità diversa da uno strumento locale.

La manutenzione preventiva include rotazione delle chiavi, revisione dei permessi, scansione delle dipendenze e gestione delle segnalazioni. Non promettere «sicurezza totale»; definisci controlli, frequenza, responsabilità e risposta.

Proprietà del codice e documentazione minima

Prima di sottoscrivere un piano, verifica che sia possibile compilare e pubblicare il progetto. Servono:

• repository completo e cronologia;
• istruzioni per ambiente, build e release;
• inventario di servizi, account, domini e proprietari;
• configurazione documentata senza secret nel repository;
• schema dati e procedura di migrazione;
• versioni supportate e account store accessibili;
• runbook per incidente, backup e ripristino.

Se manca questa base, la prima fase è una presa in carico tecnica: audit, riproduzione delle build, recupero accessi e mappa dei rischi. Separarla dal canone rende trasparente il lavoro necessario per arrivare a una gestione stabile.

Come valutare il contratto

1. applicazioni, backend e ambienti inclusi;
2. piattaforme e versioni supportate;
3. ore comprese e regole per il residuo;
4. distinzione tra difetto, adeguamento e nuova funzione;
5. orari, severità e presa in carico;
6. monitoraggio e responsabilità sugli allarmi;
7. frequenza di aggiornamento e release;
8. servizi terzi e costi a consumo;
9. proprietà del codice, account e documentazione;
10. recesso, consegna e transizione.

Un canone senza attività e limiti non permette confronto. Un pacchetto a ore senza priorità e report non garantisce che il rischio maggiore venga trattato. Chiedi un resoconto periodico: interventi, tempo usato, problemi aperti, dipendenze in scadenza e prossimo rilascio.

Un calendario minimo per non lavorare sempre in emergenza

Trasforma il piano in appuntamenti verificabili. Ogni mese controlla crash, errori del backend, consumi dei servizi e segnalazioni aperte. Prima di una release rivedi dipendenze, permessi, schede privacy e flussi critici. Ogni trimestre prova almeno build pulita, accessi operativi e ripristino dei dati previsto dal piano. Prima delle scadenze annunciate da Apple, Google o provider esterni, assegna responsabile, ambiente di prova e finestra di pubblicazione.

Il calendario non impone un rilascio a intervalli artificiali. Se non esiste una modifica utile, evita una build soltanto per rispettare una data. Serve invece a non scoprire certificati scaduti, account bloccati o incompatibilità quando l’utente è già fermo. Registra l’esito del controllo anche quando non richiede intervento: crea una cronologia utile per stimare il periodo successivo.

Dopo ogni incidente o rilascio problematico esegui una retrospettiva breve: cosa è successo, quale controllo lo avrebbe rilevato prima, quale azione ha un proprietario e quando verrà verificata. Non usare la retrospettiva per cercare colpe. Usala per aggiornare runbook, test e riserva economica con evidenze del prodotto.

Dallo sviluppo iniziale al ciclo di vita

La guida su quanto costa sviluppare un’app copre discovery, UX/UI, sviluppo, integrazioni e prima pubblicazione. Il budget di questa pagina comincia dopo: mantiene compatibilità, corregge difetti, governa servizi e accompagna la roadmap.

Il case study tecnico RouteBudget mostra decisioni di prodotto mobile, persistenza e rilascio. È un riferimento branded sulla delivery, non un listino né la prova che lo stesso piano sia adatto a un’altra app.

Per un prodotto esistente parto da repository, build, account, dipendenze, backend, store e incidenti recenti. Da queste evidenze nasce un backlog distinto tra urgenze, stabilizzazione ed evoluzione.

Domande frequenti