Quanto costa un’applicazione web su misura e da cosa dipende il prezzo

Perché non c’è un prezzo di listino

Un’applicazione web non è un prodotto: è un lavoro. Un calcolatore per un preventivo, un portale dove i clienti vedono i loro ordini e un CRM costruito sul tuo processo di vendita sono cose diverse, e il costo si muove con loro. Per questo una cifra data senza domande è un numero, non un preventivo.

Un’applicazione, a differenza di un sito, fa lavorare: gestisce dati, utenti e passaggi. Un sito racconta e fa decidere. Se quello che ti serve è presentarti e raccogliere contatti, la strada è un altro lavoro, e i costi li trovi in quanto costa un sito web aziendale.

In questo articolo ti dico da cosa dipende il prezzo, quali fasce di mercato ho trovato con le fonti e la data, quali costi arrivano dopo e come ridurre il rischio di spendere male. Sulle applicazioni non pubblico prezzi miei: li comunico dopo la fase di discovery, quando il lavoro è definito.

Da cosa dipende il prezzo

Cinque cose spiegano quasi tutta la differenza fra un preventivo e l’altro.

1. Le funzioni. Quante cose deve fare e quanto sono complesse. Un «login» può essere un semplice accesso con email e password, oppure comprendere ruoli diversi, autenticazione a due fattori e permessi per ogni utente. La parola è la stessa, il lavoro no.
2. Gli utenti. Quante persone la useranno, di che tipo, con quali permessi. Un’area dove ogni cliente vede solo i propri dati richiede più attenzione di uno strumento che usa una sola persona.
3. Le integrazioni. Il collegamento con gli strumenti che già usi: gestionale, email, calendario, pagamenti. Ogni integrazione porta un pezzo di lavoro e di verifica, e spesso è qui che sta il valore maggiore.
4. I dati. Dove vengono archiviati, chi può vederli, quanto sono sensibili. Se l’applicazione tratta dati personali, entrano in gioco regole che pesano sul progetto.
5. Il design e l’esperienza d’uso. Uno strumento interno può essere essenziale; qualcosa che usano i tuoi clienti richiede più cura nelle schermate e nei passaggi.

A queste si aggiungono il livello di prove richiesto e la manutenzione prevista dopo il lancio.

Le fasce di mercato, con le fonti

Ho cercato fonti italiane. Ne ho trovata una in euro con una tabella per tipo di applicazione, e una seconda, in dollari, che dà un confronto per livello di complessità. Sono pagine di operatori del settore, non listini: le leggo come un ordine di grandezza, e ogni riga ha la sua data.

Per tipo di applicazione, in euro (Hostinger Italia, aggiornata a settembre 2026):

Per voce di costo, in euro (Hostinger Italia, settembre 2026):

Per livello di complessità, in dollari (Utsubo, aprile 2026):

La stessa fonte dà alcuni esempi: un portale clienti tra 39.000 e 78.000 $, uno strumento operativo interno tra 30.000 e 65.000 $, uno strumento di fatturazione tra 37.000 e 75.000 $. Sono cifre indicative, come dichiara l’autore, basate su progetti tipici.

Tre avvertenze per leggere queste tabelle.

• Le due fonti non coincidono. Un CRM va da 5.000 a 50.000 € nella prima, uno strumento interno da 30.000 a 65.000 $ nella seconda. Le fasce si sovrappongono solo in parte, e questo dice che non c’è un prezzo di mercato condiviso.
• Una fonte non è coerente con se stessa. Nella pagina di Hostinger Italia alcune cifre nel testo non coincidono con quelle delle tabelle. Quando i numeri si contraddicono, mi fido meno e te lo dico.
• I dati in dollari riguardano un altro mercato. Li ho messi per avere un secondo punto di vista, non per darti un cambio.

Quello che le fonti dicono con più chiarezza è che le fasce sono larghe e che dipendono dal perimetro. Una cifra senza perimetro non dice niente.

I costi che arrivano dopo il lancio

Come per un sito, il costo di un’applicazione non finisce alla consegna.

• Hosting e infrastruttura. Dove gira l’applicazione. Hostinger indica da 5 a 500 € al mese; Utsubo, in dollari, da circa 50 a 3.000 e oltre al mese, secondo il livello.
• Manutenzione. Aggiornamenti, correzioni, piccole richieste che nascono dall’uso. Hostinger parla di 50-5.000 € al mese; Utsubo suggerisce di mettere da parte il 15-20% del costo iniziale ogni anno.
• Evoluzioni. Funzioni che emergono dall’uso vero e che all’inizio non erano previste. Sono la parte più sana del progetto, perché nascono da bisogni reali, e vanno messe in conto.
• Strumenti di terzi. Abbonamenti a servizi collegati, come posta, mappe o pagamenti.

Una buona abitudine è chiedere, già nel preventivo, una stima della parte ricorrente. Se il fornitore non sa dartela, conviene chiedersi perché.

Cosa fa salire il costo e cosa lo fa scendere

Lo fanno salire:

• molte funzioni richieste fin dall’inizio, anche quelle usate poche volte l’anno;
• tanti tipi di utente con permessi diversi;
• integrazioni con strumenti che offrono poche possibilità di collegamento;
• dati sensibili, da proteggere e da trattare con regole precise;
• requisiti che cambiano a lavoro avviato;
• nessuna persona del tuo team che conosca il processo e risponda alle domande.

Lo fanno scendere:

• una prima versione che risolve il problema principale e nient’altro;
• un processo già chiaro, descritto da chi lo vive ogni giorno;
• poche integrazioni, scelte perché danno valore;
• decisioni rapide e un riferimento unico dalla parte tua;
• uno strumento esistente usato dove basta, e il lavoro su misura solo dove serve.

La versione piccola prima di tutto

La regola che seguo è partire dalla versione più piccola che risolve il problema. Ogni funzione in più ha un costo di sviluppo e di manutenzione, e molte non servono mai. Una funzione usata due volte l’anno quasi mai si ripaga, e preferisco proporti un’alternativa semplice piuttosto che costruirla e lasciartela mantenere.

In pratica, la prima versione la usi sul lavoro vero. Le richieste successive nascono da quello che hai visto accadere, non da quello che avevi immaginato su un foglio. Si spende meno e si sbaglia meno, perché si cambia presto, quando cambiare costa poco.

Che cosa c’è dentro il prezzo di un lavoro fatto bene

Quando valuti un preventivo, conviene sapere quali fasi dovrebbe comprendere, perché ognuna ha un costo e nessuna si salta senza conseguenze.

• Discovery. Si parla con chi userà lo strumento, si guarda come lavora oggi, si decide cosa entra nella prima versione e cosa può aspettare. Costa poco rispetto al resto e fa risparmiare molto.
• Flusso e prototipo. I passaggi che una persona compie, schermata per schermata, provati su un prototipo prima di scrivere codice.
• Architettura. Le tecnologie, la struttura dei dati e le integrazioni, con i motivi spiegati in modo comprensibile anche a chi non è tecnico.
• Sviluppo a tappe. Una versione da provare a ogni tappa, così se serve cambiare rotta lo si fa presto e a basso costo.
• Prove e messa online. Ogni funzione verificata con casi reali, poi l’applicazione online e tenuta sotto osservazione dopo il lancio.
• Formazione e passaggio di consegne. Chi la userà viene formato, e ricevi documentazione e codice nel tuo repository.

Un preventivo che non nomina queste fasi, o ne nomina solo una, non è sbagliato per forza. Ma conviene chiedere dove stanno le altre, e chi se ne occupa.

Applicazione su misura o strumento pronto

Non sempre serve costruire. Se un software già pronto copre quasi tutto ciò che ti serve, di solito conviene quello. Gli strumenti no-code, che le fonti mettono a confronto con lo sviluppo, hanno costi annui molto più bassi, e per esigenze semplici possono bastare.

Un’applicazione su misura ha senso quando:

• il tuo processo è specifico e gli strumenti standard ti obbligano a lavorarci intorno;
• paghi per decine di funzioni e ne usi due;
• i tuoi dati stanno in posti che non si parlano e li ricomponi a mano;
• vuoi un asset che resta tuo e non dipende dal listino di qualcun altro.

Se la tua esigenza è più vicina all’automazione di compiti ripetitivi che a un software vero e proprio, a volte basta quello e costa meno: ne parlo nella pagina su AI e automazioni.

Un esempio: Talaria

Il mio esempio più completo è Talaria, un CRM per gestire contatti, conversazioni e appuntamenti di agenzie e clienti. L’ho progettato e costruito io, dal flusso dei dati alle schermate, insieme al sito che lo presenta. Non è un caso studio con i risultati di un cliente, quindi non ho numeri da mostrarti: lo cito per far vedere come lavoro, non per darti una misura. Per un progetto tuo, la cifra dipende da quello che ti serve.

Come chiedere un preventivo che si possa confrontare

Il modo più sicuro di confrontare due offerte è dare a entrambe lo stesso brief.

Con questi cinque punti scritti, il confronto fra preventivi diventa un confronto su cose uguali, e le differenze di prezzo si spiegano. Se invece non sai ancora quale sia il problema da risolvere, la domanda che viene prima è quella, e un preventivo non basta a rispondere. Come lavoro sulle applicazioni lo trovi nella pagina su applicazioni web su misura. Per un sito con esigenze particolari, prima di arrivare a un’applicazione, leggi WordPress o sito su misura.