La domanda che sposta il prezzo di un'app non è quante schermate ha, ma se ti serve davvero un'app: se una PWA risolve lo stesso problema, il costo si riduce a una frazione. Quando serve davvero, il prezzo dipende da quante funzioni entrano nella prima versione e da quanto backend va costruito. Da noi si parte da poche centinaia di euro.
Prima domanda: ti serve davvero un'app?
È la domanda che fa risparmiare più soldi di qualsiasi negoziazione sul preventivo. Un'app ha senso quando l'utente torna spesso, quando servono funzioni del dispositivo (fotocamera, GPS, notifiche, uso offline) o quando la app è il prodotto. Per tutto il resto, un sito responsive o una PWA fanno lo stesso lavoro a un terzo del costo, senza store da attraversare e senza chiedere all'utente di installare qualcosa.
| Obiettivo | Soluzione adeguata | Impegno relativo |
|---|---|---|
| Farsi trovare e ricevere contatti | Sito web | Il più contenuto |
| Vendere prodotti online | E-commerce | Contenuto, cresce col catalogo |
| Strumento interno per il team | Web app o PWA | Medio |
| Uso frequente da parte dei clienti, con notifiche | App cross-platform | Alto |
| Lavoro sul campo senza rete, con fotocamera e GPS | App nativa o cross-platform avanzata | Il più alto |
Nativo, cross-platform o PWA: cosa cambia sul preventivo
| Approccio | Costo relativo | Vantaggi | Limiti |
|---|---|---|---|
| PWA (app web installabile) | Circa un terzo del nativo | Una base di codice, nessuno store, aggiornamenti immediati, indicizzabile da Google | Notifiche più limitate su iOS, niente vetrina sugli store |
| Cross-platform (React Native, Flutter) | Circa due terzi del nativo | Una base per iOS e Android, presenza sugli store, accesso alle funzioni del dispositivo | Qualche limite su grafica 3D e funzioni molto specifiche |
| Nativo (Swift + Kotlin) | Il riferimento | Massime prestazioni, accesso immediato alle novità di sistema | Due basi di codice da scrivere e mantenere: tempi quasi raddoppiati |
Per la grande maggioranza dei progetti aziendali il cross-platform è la scelta corretta. Il nativo si giustifica per app ad alta intensità grafica, elaborazione in tempo reale o requisiti di sistema molto specifici.
Dove finiscono davvero i soldi
| Fase | Quota del budget | Cosa comprende |
|---|---|---|
| Analisi e definizione | 10-15% | Funzioni, flussi, casi limite, requisiti degli store. |
| Design UI/UX | 15-20% | Prototipi, schermate, stati, animazioni, linee guida iOS e Android. |
| Sviluppo app | 35-45% | La parte visibile: schermate, logica, navigazione, offline. |
| Backend e API | 15-25% | Quasi sempre sottostimata: è il motore che fa funzionare tutto. |
| Test e pubblicazione | 10-15% | Dispositivi reali, versioni di sistema, revisione degli store, correzioni. |
Se un preventivo dedica il 5% al backend e il 70% alle schermate, è quasi certo che il backend verrà rifatto in corsa.
I costi che iniziano dopo la pubblicazione
| Voce | Note |
|---|---|
| Iscrizione agli store Apple e Google | Quote annuali contenute, ma gli account devono essere intestati alla tua azienda |
| Infrastruttura e backend | Cresce con utenti e dati |
| Manutenzione e aggiornamenti di sistema | Non opzionale: iOS e Android cambiano ogni anno |
| Notifiche, analytics, monitoraggio errori | Contenute, spesso con piani gratuiti sufficienti |
| Nuove funzioni | Variabile, ma sempre presente se l'app viene usata |
Ogni anno iOS e Android rilasciano una versione maggiore. Un'app non aggiornata smette di funzionare correttamente in 12-24 mesi e può essere rimossa dallo store: la manutenzione non è opzionale.
Come ridurre il costo senza compromettere il risultato
- Parti da una PWA per validare l'interesse. Se le persone la usano, l'app nativa avrà un business case; se non la usano, hai risparmiato l'intero progetto.
- Riduci le funzioni della prima versione a quelle senza cui l'app non ha senso. Tutto il resto è la versione 1.1.
- Riusa il backend che hai già: se esiste un gestionale o un e-commerce, l'app può appoggiarsi a quello invece di duplicarlo.
- Progetta prima per il dispositivo più diffuso tra i tuoi utenti: sapere che l'85% è su Android cambia le priorità di test.
- Rinuncia alle animazioni personalizzate nella prima versione: costano molto e non sono ciò che fa tornare gli utenti.
I livelli di progetto
Un'idea da validare o uno strumento interno con poche funzioni ben definite.
- Cross-platform (una base di codice per iOS e Android)
- 8-15 schermate
- Login e profilo utente
- Backend leggero e API
- Pubblicazione su App Store e Google Play
App destinate ai clienti, con contenuti dinamici e un ciclo di vita pluriennale.
- Design UI/UX su misura per entrambe le piattaforme
- Notifiche push segmentate
- Integrazioni con CRM, gestionale o e-commerce
- Pannello di amministrazione web
- Analytics prodotto e monitoraggio crash
App che sono il prodotto stesso, o strumenti operativi critici sul campo.
- Funzionamento offline e sincronizzazione
- Pagamenti in-app e abbonamenti
- Mappe, geolocalizzazione, scansione, fotocamera
- Sviluppo nativo dove le prestazioni lo richiedono
- Sicurezza, audit e conformità
Domande frequenti
- Quanto costa un'app per iOS e Android?
- Con l'approccio cross-platform, che copre entrambe le piattaforme con una sola base di codice, si parte da poche centinaia di euro. Lo sviluppo nativo separato per le due piattaforme costa sensibilmente di più, perché sono due progetti da scrivere e mantenere.
- Quanto tempo serve per sviluppare un'app?
- Tra 3 e 4 mesi per un'app essenziale, 5-8 mesi per un'app di prodotto. Alla fine va aggiunto il tempo di revisione degli store: Apple impiega normalmente 1-3 giorni, ma un rifiuto può aggiungere una o due settimane.
- Meglio un'app nativa o una PWA?
- La PWA conviene quando l'obiettivo è raggiungere l'utente senza chiedergli di installare nulla, e quando le funzioni richieste sono coperte dal browser. L'app nativa o cross-platform serve quando servono notifiche affidabili su iOS, uso offline serio, accesso profondo all'hardware o presenza sugli store come canale di acquisizione.
- Quanto costa mantenere un'app ogni anno?
- La manutenzione va messa a budget come quota annuale del progetto e copre aggiornamenti di sistema, correzioni, infrastruttura e piccole evoluzioni. Non è opzionale: iOS e Android rilasciano una versione maggiore ogni anno, e un'app non aggiornata smette di funzionare correttamente entro un anno o due.
- Posso far sviluppare l'app all'estero per risparmiare?
- Puoi, e la tariffa oraria scende. Quello che cresce è il costo di coordinamento: fuso orario, lingua, differenze nella comprensione del contesto normativo e commerciale italiano. Funziona bene con specifiche molto precise e un product owner interno forte; funziona male quando il progetto è ancora da definire.
- Cosa serve per pubblicare sugli store?
- Un account sviluppatore Apple e uno Google, con quote annuali contenute, intestati alla tua azienda e non all'agenzia. Servono inoltre privacy policy, dichiarazione sui dati raccolti, icone, immagini e descrizioni: l'insieme richiede qualche giorno di lavoro, ed è il punto in cui si verifica la maggior parte dei rifiuti.
- Un'app può sostituire il sito web?
- No, e sono complementari: il sito ti fa trovare da chi non ti conosce, l'app serve chi ti conosce già e torna spesso. Un'app non è indicizzata su Google e richiede un'installazione: come unico canale digitale è quasi sempre una scelta sbagliata.