App mobile

Manutenzione app: costi e responsabilità dopo il lancio

Pubblicare la prima versione non chiude il progetto: cambia il tipo di lavoro. Questa guida separa bug, aggiornamenti tecnici, infrastruttura e nuove funzioni, così puoi confrontare un piano di assistenza senza affidarti a percentuali generiche.

A cura di ContatPubblicato il 11 min di lettura

Correttiva

Ripristina un comportamento concordato che non funziona come previsto.

Adattiva

Mantiene compatibilità con sistemi operativi, store, SDK e servizi esterni.

Preventiva

Aggiorna dipendenze, osservabilità, backup e controlli prima che diventino emergenze.

Evolutiva

Aggiunge o modifica funzioni: è sviluppo nuovo, non correzione di un difetto.

Operativa

Copre backend, database, code, notifiche, dominio, certificati e costi a consumo.

Livello di servizio

Definisce canale, priorità, reperibilità e tempi di presa in carico per incidenti diversi.

Un’app appena pubblicata può essere stabile e avere comunque bisogno di manutenzione. iOS e Android cambiano, gli store aggiornano i requisiti, le librerie ricevono correzioni di sicurezza, i certificati scadono e i servizi collegati modificano le loro API. Nel frattempo arrivano utenti, nuovi dispositivi e richieste che il progetto iniziale non poteva conoscere.

Il problema non è soltanto prevedere un budget. È capire che cosa viene chiamato ‘manutenzione’. Se ogni attività finisce nello stesso contenitore, diventa impossibile distinguere una responsabilità del fornitore da una nuova richiesta o da una spesa esterna. Prima di confrontare offerte, conviene separare le voci.

Cinque lavori diversi che spesso hanno lo stesso nome

Cinque lavori diversi che spesso hanno lo stesso nome

Manutenzione correttiva. Risolve un difetto rispetto al comportamento concordato. Se il capitolato dice che un utente autorizzato può scaricare una fattura e il pulsante produce un errore, si tratta di una correzione. Per decidere senza discussioni servono requisiti e criteri di accettazione chiari: ‘non mi piace più questo flusso’ è una richiesta diversa da ‘questo flusso non fa ciò che abbiamo approvato’.

Manutenzione adattiva. Adegua l’app a un ambiente che è cambiato: una nuova versione del sistema operativo, una regola dello store, una libreria non più supportata, un’API esterna aggiornata. L’app non è necessariamente stata progettata male; vive dentro un ecosistema che continua a muoversi.

Manutenzione preventiva. Riduce la probabilità di incidenti futuri. Comprende aggiornamento delle dipendenze, revisione di log e alert, prove di ripristino, rimozione di componenti obsoleti e correzioni emerse da controlli di sicurezza. È il lavoro meno visibile e spesso quello che evita le urgenze più costose.

Manutenzione operativa. Tiene in funzione ciò che sta dietro l’icona: server o funzioni cloud, database, storage, email, notifiche push, code, certificati, backup, monitoraggio e servizi di terze parti. Alcune voci sono lavoro; altre sono consumi fatturati direttamente dai fornitori.

Evoluzione. Una nuova schermata, un ruolo aggiuntivo, un diverso processo di pagamento o un’integrazione non prevista sono sviluppo evolutivo. Possono essere piccoli cambiamenti, ma modificano il perimetro. Chiamarli ‘manutenzione’ non li rende gratuiti né li rende automaticamente inclusi.

Cosa determina davvero il costo dopo il lancio

Cosa determina davvero il costo dopo il lancio

Non esiste una percentuale affidabile per ogni app. Due prodotti costati uguale possono richiedere cure molto diverse. Il budget dipende soprattutto da:

  • Criticità: un catalogo consultivo tollera un’interruzione diversamente da un’app usata per ordini, salute, pagamenti o lavoro sul campo.
  • Numero di ambienti: app iOS e Android, pannello web, backend e integrazioni allargano la superficie da verificare.
  • Dipendenze esterne: pagamenti, mappe, identità, CRM, ERP e dispositivi hardware possono cambiare senza seguire la tua roadmap.
  • Volumi e variabilità: utenti, file, notifiche, query e traffico incidono su infrastruttura e osservabilità.
  • Requisiti di servizio: assistenza in orario lavorativo e presa in carico continua hanno organizzazione e costi differenti.
  • Frequenza dei rilasci: accumulare modifiche per mesi riduce alcune attività di distribuzione, ma aumenta la dimensione e il rischio di ogni rilascio.
  • Qualità della base tecnica: test automatici, ambienti separati, log leggibili e procedure di rilascio riducono il tempo necessario a diagnosticare e verificare.

Per costruire un budget, elenca prima le attività ricorrenti e gli eventi possibili. Separa un canone o pacchetto per monitoraggio e manutenzione programmata, una capacità riservata per incidenti e un processo di stima per l’evoluzione. Aggiungi i costi vivi intestati al cliente: account store, cloud, database, email, mappe, SMS, analytics o altri servizi scelti.

La pagina su quanto costa creare un’app descrive il progetto iniziale; questo conto post-lancio deve invece essere collegato all’architettura e all’uso reale. Chiedi sempre quali ipotesi di traffico e storage sostengono la stima e cosa accade quando vengono superate.

Aggiornamenti di store e sistemi operativi non sono facoltativi

Apple e Google pubblicano requisiti per l’invio e la disponibilità delle app. Le App Review Guidelines di Apple coprono sicurezza, funzionamento, modello di business, design e aspetti legali; vanno ricontrollate a ogni rilascio rilevante. Google applica requisiti periodici sul livello API target: la pagina ufficiale di Play Console indica requisiti e scadenze applicabili a nuove app, aggiornamenti e app esistenti.

Queste regole cambiano: una guida seria deve rimandare alla fonte corrente, non trasformare una scadenza annuale in una promessa eterna. Nel piano di manutenzione stabilisci chi controlla gli annunci, chi valuta l’impatto, chi prepara la build e chi possiede gli accessi necessari alla pubblicazione.

Gli account possono essere intestati all’azienda cliente quando richiesto. È una scelta utile per continuità e controllo, ma richiede governance: almeno due persone abilitate dove possibile, autenticazione forte, recupero documentato e ruoli minimi. Condividere una password personale in chat non è una strategia di consegna.

Backend e integrazioni possono rompersi senza aggiornare l’app

Molte anomalie percepite come ‘problemi dell’app’ nascono altrove. Il database raggiunge un limite, una chiave API scade, un certificato non viene rinnovato, il provider di email rallenta o il gestionale cambia formato. Per questo il monitoraggio deve seguire il servizio completo, non soltanto i crash sul telefono.

Un set essenziale comprende errori applicativi, disponibilità degli endpoint, tempi di risposta, code bloccate, fallimenti di login e pagamento, scadenza di certificati, spazio del database e riuscita dei backup. Gli alert devono arrivare a qualcuno che abbia accesso e responsabilità; accumularli in una casella non letta produce soltanto rumore.

Per ogni API esterna annota proprietario, documentazione, versione, limiti, ambiente di test e procedura in caso di indisponibilità. Se un evento arriva tramite webhook, verifica retry, idempotenza e riconciliazione: perdere una notifica di pagamento non dovrebbe rendere impossibile ricostruire lo stato.

Sicurezza e privacy richiedono attività verificabili

‘Tenere l’app sicura’ è troppo vago per un contratto. È più utile elencare controlli: aggiornamento delle dipendenze, gestione delle vulnerabilità, revisione degli accessi, rotazione delle credenziali, verifica dei log, backup cifrati dove necessario e prove di ripristino. L’OWASP Mobile Application Security Verification Standard offre un riferimento pubblico per definire e verificare controlli tecnici sulle app mobili.

La privacy non si esaurisce con un testo nello store. Se cambiano dati raccolti, finalità, fornitori o tempi di conservazione, vanno rivalutati flusso, informative e configurazioni. Coinvolgi il referente privacy o un professionista quando il trattamento lo richiede; il team tecnico implementa decisioni e misure, non sostituisce la consulenza legale.

Come scrivere un piano di assistenza confrontabile

Un documento utile risponde almeno a queste domande:

  • Quali componenti sono coperti: app, backend, pannello, integrazioni e infrastruttura?
  • Quali attività sono programmate e con quale frequenza?
  • Come vengono classificate priorità e impatto di un incidente?
  • Quali sono canale e orari di assistenza, tempo di presa in carico e modalità di aggiornamento?
  • Che cosa è un bug rispetto ai criteri approvati e che cosa è una modifica?
  • Quante versioni dei sistemi operativi e quali dispositivi rientrano nei test?
  • Chi controlla store, dipendenze, certificati, backup e costi cloud?
  • Come si autorizzano ore o budget aggiuntivi?
  • Che report riceve il cliente: incidenti, rilasci, consumo, rischi e attività completate?
  • Cosa viene consegnato se il rapporto termina?

Un SLA non dovrebbe promettere che ogni problema sarà risolto entro poche ore: la diagnosi può dipendere da terzi o richiedere una nuova revisione dello store. È più serio distinguere tempo di presa in carico, aggiornamenti durante l’incidente, soluzione temporanea e ripristino definitivo.

Il contratto deve proteggere continuità e libertà operativa

Prima di firmare, verifica accesso al repository, documentazione di avvio, account, ambienti, procedura di build, elenco dei servizi esterni e backup. Il valore non è una formula astratta di ‘proprietà totale’: è poter usare e far manutenere il codice consegnato per tutta la vita del progetto commissionato, secondo gli accordi, senza dipendere da una sola persona. Componenti preesistenti, riutilizzabili e software di terze parti mantengono le rispettive titolarità e licenze.

Con Contat il cliente accede al repository Git dall’inizio e può usare e far manutenere il codice consegnato senza limiti di tempo per l’intera vita del progetto commissionato, anche dopo un trasferimento secondo gli stessi accordi. Prima della firma comunichiamo le persone assegnate e gli eventuali collaboratori esterni; Contat è il marchio condiviso di una rete di circa 22 professionisti tra sviluppo, marketing, social, design e video. Il capitolato definisce funzioni incluse ed escluse, account, proprietà intellettuale, sicurezza, backup, privacy, GDPR, tempi, ritardi, recesso e consegna incompleta. Manutenzione, correzione dei bug e modifiche successive per i primi 12 mesi hanno perimetro e costi definiti e inclusi nel progetto; prima dello sviluppo completo validiamo una demo o un prototipo.

Una routine sostenibile per il primo anno

Subito dopo il lancio osserva crash, errori backend, tempi di risposta, ticket e percorso principale. Nelle prime settimane conviene rilasciare correzioni piccole e verificabili, senza confondere ogni feedback con una priorità. Ogni mese rivedi dipendenze, costi cloud, alert e richieste; a ogni trimestre prova il ripristino, controlla accessi e aggiorna la roadmap. Prima delle scadenze e dei cambi di requisito annunciati da Apple e Google pianifica test e adeguamenti con anticipo.

La frequenza non è universale: un’app interna usata da venti persone e un servizio pubblico con pagamenti richiedono ritmi diversi. La costante è avere un responsabile, dati per decidere e un percorso di rilascio ripetibile. Se nessuno sa chi deve accorgersi di un problema, il contratto di manutenzione non sta ancora coprendo il rischio principale.

Per descrivere architettura, criticità e budget puoi partire da Smartquote. La prima valutazione è gratuita e la stima di costi e tempi viene formulata da una persona dopo aver letto il contesto.

Domande sulla manutenzione dell’app

Dipende dal contratto e dai criteri di accettazione. Un bug è uno scostamento dal comportamento concordato; una nuova esigenza o un cambio di flusso è sviluppo evolutivo. Definire la distinzione prima del lancio evita discussioni successive.
Per mantenere compatibilità con sistemi operativi, requisiti degli store, SDK e servizi collegati, oltre a correggere vulnerabilità e componenti non più supportati. Rimandare può ridurre disponibilità, sicurezza o possibilità di pubblicare nuovi aggiornamenti.
La loro gestione può rientrare nel servizio, ma i consumi vanno indicati separatamente. Il piano dovrebbe elencare provider, intestazione degli account, soglie considerate, alert e responsabilità quando traffico o storage superano le ipotesi iniziali.
Possono essere intestati al cliente quando richiesto, così l’azienda mantiene controllo e continuità. Vanno però configurati ruoli, autenticazione forte, recupero e accessi del team senza condividere credenziali personali in modo informale.
Repository e storico, documentazione di avvio e rilascio, accessi agli ambienti, configurazioni e variabili senza esporre segreti, stato di backup e monitoraggio, elenco di dipendenze e servizi, problemi aperti e versioni pubblicate. Il dettaglio va definito nel contratto.

Vuoi sapere cosa serve davvero alla tua app dopo il lancio?

La prima chiamata è gratuita. Partiamo da architettura, utenti e criticità per separare manutenzione, infrastruttura e roadmap in un piano leggibile.