La maggior parte delle PMI che mi chiede un'app non ha bisogno di un'app.
Lo dico all'inizio perché è la parte che di solito non viene detta, e perché mi ha fatto perdere qualche lavoro ma mi ha evitato di consegnare cose che sarebbero morte in sei mesi. Un'app che nessuno scarica costa esattamente quanto un'app di successo, con la differenza che continua a costare anche dopo, senza restituire niente.
Quindi partiamo dalla domanda scomoda, prima di quella sui costi.
Il test delle tre domande
Un'app mobile nativa ha senso quando fa qualcosa che un sito ben fatto sul telefono non può fare. Non "fa peggio": non può proprio fare.
Prima domanda: serve funzionare senza rete? Un tecnico che compila rapporti in un capannone senza campo, un agente che prende ordini in una zona scoperta, un ispettore in un'area senza connessione. Il browser lì si ferma, un'app con sincronizzazione differita no.
Seconda domanda: serve accedere all'hardware del telefono in modo continuativo? Scansione di codici a barre a raffica, fotocamera come strumento di lavoro, GPS che traccia in background mentre l'app è chiusa, lettura NFC, stampa su dispositivi bluetooth.
Terza domanda: le persone che la useranno la apriranno tutti i giorni? Un'app usata quotidianamente da chi lavora si giustifica quasi sempre. Un'app che il cliente finale aprirebbe due volte l'anno non si giustifica quasi mai, perché prima di aprirla dovrebbe ricordarsi di averla installata.
Se hai risposto no a tutte e tre, quello che ti serve è probabilmente un sito responsive fatto bene, o una web app installabile sulla schermata home. Costa una frazione, si aggiorna senza passare dagli store, e nessuno deve scaricare niente.
Se hai risposto sì almeno alla prima o alla seconda, allora l'app serve davvero, e vale la pena parlare di come si fa.
Dove un'app si ripaga quasi sempre
Lo scenario in cui vedo il ritorno più netto è l'operatività sul campo: persone che lavorano fuori dall'ufficio e che oggi raccolgono dati su carta o su un foglio di calcolo, per poi ribatterli al rientro.
È il caso su cui abbiamo costruito ParkCheck, il nostro prodotto per la gestione delle aree gioco. Il tecnico esegue l'ispezione sul posto, con o senza campo, fotografa le non conformità, e il rapporto è già compilato quando risale in macchina. Prima quello stesso lavoro era una scheda cartacea, ribattuta la sera, con le foto da associare a mano.
Il guadagno non è il tempo dell'ispezione: è quello che c'è dopo. La doppia digitazione sparisce, e con lei spariscono gli errori di trascrizione e i rapporti che arrivano in ritardo.
È il motivo per cui suggerisco di misurare il ritorno di un'app sul processo a valle, non sull'attività in sé. Se venti persone risparmiano venti minuti al giorno di lavoro amministrativo, l'app si ripaga in fretta. Se il risparmio è solo teorico perché quei venti minuti nessuno li stava contando, l'investimento è più difficile da difendere.
Su costi e tecnologia c'è già una guida
Range di prezzo, differenze fra sviluppo nativo e cross-platform e voci di costo che saltano fuori a progetto avviato li ho già affrontati per esteso: quanto costa sviluppare un'app mobile nel 2026, con i range per tipo di progetto e dove si può tagliare senza rovinare il risultato.
Qui mi interessa la parte che quell'articolo non copre, e che è quella che decide se l'investimento produce qualcosa: capire prima se l'app serve davvero, e cosa succede dopo la consegna.
Il costo che nessuno mette a budget
Sul prezzo di sviluppo si contratta, e va bene. Il problema è un altro, e riguarda tutti allo stesso modo.
Un'app non è un progetto che finisce. Android e iOS rilasciano una versione maggiore all'anno, e ogni anno qualcosa smette di funzionare: un permesso che cambia, una libreria deprecata, un requisito nuovo degli store. Se l'app non viene aggiornata, prima si comporta in modo strano su qualche dispositivo, poi smette di essere accettata dallo store, infine non si installa più.
La manutenzione di un'app va messa a budget dal primo giorno, e vale sia per gli aggiornamenti di compatibilità sia per la ripubblicazione periodica sugli store. È la voce che trasforma un'app in un asset che dura anni invece che in un investimento con scadenza silenziosa.
Vale la pena chiarire due cose con chi la sviluppa, prima di firmare:
Chi possiede il codice sorgente e gli account degli store? Devono essere intestati alla tua azienda, non al fornitore. È la stessa logica del dominio del sito: se un domani cambi fornitore, l'app resta tua.
Chi si occupa degli aggiornamenti di compatibilità, con quali tempi? È il punto in cui un piano di manutenzione con tempi definiti vale molto più di un accordo generico.
Come si capisce se è servita
È la domanda che nessuno prepara prima di partire, e senza una risposta il progetto non si può giudicare: fra un anno ci sarà chi dice che l'app è stata utile e chi dice di no, entrambi senza dati.
Le misure che funzionano per un'app interna sono tre, e vanno fissate prima di sviluppare, con il numero di partenza scritto da qualche parte.
Quante volte al giorno viene aperta da chi dovrebbe usarla. Non i download: le aperture. Un'app installata su venti telefoni e aperta da sei persone ha un problema di adozione, e nessuna funzione aggiuntiva lo risolve.
Quanto tempo si è tolto al lavoro amministrativo a valle. È il vero ritorno di un'app di campo: non l'attività sul posto, ma la ribattitura serale che sparisce. Misuralo cronometrando due settimane prima e due settimane dopo, con le stesse persone.
Quanti errori di trascrizione sono spariti. Se prima una scheda su venti tornava indietro per un dato illeggibile o sbagliato, quel numero è il beneficio più facile da difendere davanti a chi ha firmato la spesa.
Se dopo tre mesi nessuna delle tre si è mossa, il problema non è tecnico: l'app sta chiedendo alle persone di lavorare come prima con uno strumento in più.
Le tre domande da mettere per iscritto
Chi possiede il codice sorgente? Deve essere la tua azienda. Se resta del fornitore, ogni evoluzione futura passa da lui al prezzo che deciderà, e non hai alternative.
A nome di chi sono gli account degli store? Vanno intestati all'azienda, non all'agenzia. È la stessa logica del dominio del sito: se cambi fornitore, l'app deve restare tua e pubblicata dove è sempre stata. Recuperare un'app pubblicata sotto l'account di qualcun altro è un procedimento lungo e talvolta impossibile.
Con quali tempi vengono fatti gli aggiornamenti di compatibilità? Non "quando serve": entro quanto dall'uscita di una nuova versione di Android o iOS, e cosa succede se una funzione smette di funzionare nel frattempo. Un piano di manutenzione con tempi dichiarati vale molto più di un accordo generico.
Come procedere senza rischiare troppo
Il modo più sicuro di sbagliare è partire dall'app completa con tutte le funzioni immaginate nelle riunioni.
Il modo più sicuro di riuscire è partire da una versione minima che risolve un solo problema, quello che fa più male, e metterla in mano alle persone che dovranno usarla davvero. Non ai responsabili: agli utenti finali.
Quello che succede quasi sempre è che metà delle funzioni previste si rivelano inutili, e ne emergono due o tre a cui nessuno aveva pensato e che sono quelle che decidono se l'app verrà usata o abbandonata. Scoprirlo su una versione minima costa poco. Scoprirlo a progetto finito costa il progetto.
Come lavoriamo
Partiamo sempre dalle tre domande dell'inizio, e capita regolarmente che la risposta onesta sia "non ti serve un'app". Quando invece serve, lavoriamo per fasi definite, con la pubblicazione sugli store e il supporto post-lancio inclusi, e un piano di manutenzione con tempi di intervento concordati per gli aggiornamenti di compatibilità Android e iOS.
Se hai in mente un processo che oggi gira su carta o su fogli di calcolo e vuoi capire se ha senso portarlo su mobile, raccontacelo: ti diciamo con franchezza se conviene, e in caso affermativo hai un preventivo in 24 ore.
Hai un processo da portare su mobile?
Ti diciamo con franchezza se un'app conviene davvero. In caso affermativo, preventivo in 24 ore.
Parliamone
