Una web app quanto costa davvero nei primi 24 mesi? Le fasce editoriali disponibili partono da 5.000 euro per alcuni progetti affidati a un freelance senior e superano 200.000 euro per applicazioni complesse, ma il dato utile è il costo totale: progettazione, sviluppo, infrastruttura, assistenza e modifiche.

Il prezzo iniziale racconta solo una parte. Per capire quale preventivo conviene bisogna leggere quattro fatture immaginarie: quella del mese 0 per analisi e progettazione, quella del mese 4 per lo sviluppo, quella del mese 12 per mantenere il servizio operativo e quella del mese 24 per aggiornamenti, problemi ed evoluzioni.

  • Mese 0: analisi dei requisiti, progettazione dell’esperienza utente e prototipi.
  • Mese 4: sviluppo, collaudo, configurazione dell’infrastruttura e pubblicazione.
  • Mese 12: hosting, database gestito, backup, monitoraggio e correzione dei difetti.
  • Mese 24: nuove funzioni, adeguamenti, interventi urgenti e aumento delle risorse tecniche.

Se il preventivo parla solo della seconda fattura, il confronto è incompleto. Il costo rimasto fuori riapparirà più avanti, spesso quando cambiare fornitore sarà già diventato difficile.

Web app quanto costa nelle fasce pubblicate dai fornitori

Le cifre disponibili non sono un tariffario ufficiale. Sono fasce editoriali pubblicate da fornitori e vanno lette tenendo conto di funzioni, qualità richiesta e responsabilità incluse.

  • Agenzia tradizionale: 15.000–50.000+ euro, con tempi indicativi di 3–6 mesi, secondo AppVeloce.
  • Freelance senior: 5.000–15.000 euro e 2–4 mesi, sempre secondo AppVeloce.
  • Servizio SaaS esistente: 50–500 euro al mese. In 24 mesi significa 1.200–12.000 euro di soli canoni, prima di eventuali configurazioni e attività esterne.
  • Applicazione di media complessità: 20.000–70.000 euro, nella classificazione proposta da Do Agency.
  • Applicazione complessa: 70.000–200.000+ euro, secondo la stessa fonte.

Le fasce si sovrappongono perché le etichette non sono standard. Una “media complessità” può comprendere un pannello amministrativo, diversi profili utente e collegamenti con sistemi esterni. Per un altro fornitore, lo stesso termine può indicare molto meno.

Il confronto corretto parte quindi dall’elenco delle funzioni consegnate. Servono anche i tempi, i criteri di collaudo, il periodo di assistenza e le spese ricorrenti. Un importo basso senza questi elementi è soltanto un numero con parecchie righe ancora da compilare.

Quali decisioni generano le fatture dei mesi 0 e 4

Discovery e progettazione dell’esperienza utente

La discovery è la fase in cui si chiarisce che cosa deve fare l’applicazione, per chi e con quali vincoli. Comprende la raccolta dei requisiti, cioè delle funzioni e delle condizioni operative, la mappa dei percorsi utente e le priorità.

La progettazione UX, o esperienza utente, stabilisce come una persona completa un’operazione. Per esempio: registrarsi, cercare un ordine, caricare un documento o autorizzare un pagamento. Il prototipo permette di verificare questi passaggi prima di scrivere il codice.

Tagliare questa fase riduce la prima fattura, ma trasferisce le decisioni nello sviluppo. Una modifica su un prototipo richiede una correzione grafica. La stessa modifica, quando database e funzioni sono già collegati, può coinvolgere più parti del sistema.

Sviluppo e collaudo

Il costo cresce con il numero di ruoli, regole e integrazioni. Un catalogo consultabile è diverso da un portale in cui clienti, operatori e amministratori vedono dati differenti. Un modulo che salva una richiesta è diverso da una procedura che controlla disponibilità, autorizzazioni e stato di una pratica.

Nel preventivo vanno distinti almeno:

  • interfaccia visibile agli utenti;
  • logica applicativa, cioè le regole eseguite dal sistema;
  • database e gestione dei dati;
  • collegamenti con servizi esterni;
  • pannello di amministrazione;
  • test, correzioni e criteri di accettazione;
  • messa online e passaggio delle conoscenze al committente.

La parola “completo” non sostituisce l’elenco. Se una funzione non è descritta, diventerà facilmente una richiesta aggiuntiva.

Hosting, database e manutenzione nelle fatture dei mesi 12 e 24

Una web app pubblicata deve continuare a funzionare. L’infrastruttura comprende le risorse cloud o i server che eseguono il programma, lo spazio per i dati, i backup e gli strumenti di controllo.

PostgreSQL, un diffuso sistema per gestire database, è open source e gratuito, come rileva Capterra. Questo non rende gratuito il database in esercizio. Un servizio gestito, le risorse cloud, le copie di sicurezza e l’assistenza restano a pagamento. Microsoft Azure descrive inoltre PostgreSQL in relazione a servizi gestiti e possibilità di scalare le risorse, cioè aumentarle quando carico e dati crescono.

Il capitolato dovrebbe separare quattro attività che nei preventivi vengono spesso accorpate:

  • Monitoraggio: controllare disponibilità, errori e consumo delle risorse.
  • Manutenzione correttiva: eliminare difetti rispetto alle funzioni concordate.
  • Aggiornamento evolutivo: aggiungere o modificare funzioni richieste dopo la consegna.
  • Gestione delle emergenze: intervenire su blocchi, perdita di servizio o problemi che richiedono priorità.

Per ogni voce servono responsabilità e tempi. “Assistenza inclusa” può significare una risposta entro poche ore oppure la semplice presa in carico senza una scadenza. Può coprire i difetti oppure qualsiasi richiesta. Sono differenze economiche, non dettagli lessicali.

Va chiarito anche chi paga l’aumento delle risorse. Se utenti, file o operazioni crescono, il canone iniziale può non bastare. Un’offerta seria spiega almeno come viene misurato il consumo e chi autorizza il passaggio a una configurazione più costosa.

Funzioni, interfaccia e piattaforma cambiano il preventivo

Le voci che incidono di più non sono sempre quelle visibili. Un’interfaccia semplice può nascondere controlli articolati, collegamenti con gestionali e regole diverse per ogni tipo di utente.

Prima di chiedere un prezzo conviene definire:

  • quanti profili utente esistono e che cosa può fare ciascuno;
  • quali dati vengono inseriti, modificati e conservati;
  • quali sistemi esterni devono scambiare informazioni con l’applicazione;
  • quante schermate e procedure operative sono necessarie;
  • quali dispositivi e browser devono essere supportati;
  • quali volumi di utenti e operazioni sono previsti;
  • chi gestisce contenuti, utenze e configurazioni.

Anche la scelta della piattaforma cambia il conto. Un SaaS, cioè un servizio già pronto usato tramite abbonamento, costa secondo AppVeloce 50–500 euro al mese. Può essere adatto quando il processo aziendale segue funzioni già disponibili. Riduce lo sviluppo iniziale, ma lascia al fornitore limiti, tempi di aggiornamento e struttura del canone.

Lo sviluppo su misura richiede un investimento maggiore, ma consente di progettare regole e flussi specifici. La domanda utile non è quale soluzione sia migliore in assoluto. È quanto costa adattare l’azienda al software esistente rispetto a quanto costa costruire e mantenere un prodotto dedicato.

Quando la richiesta è soltanto un nome

Una ricerca come “web app FC 26” non descrive ancora un progetto. Potrebbe riferirsi a un portale informativo, a un’interfaccia collegata a un servizio esistente o a un prodotto con funzioni proprie. Per stimare il costo servono operazioni, utenti, dati, integrazioni e diritti di accesso. Il nome cercato non può prendere il posto dei requisiti.

Due offerte uguali possono distribuire i rischi in modo opposto

Due preventivi da 30.000 euro possono sembrare equivalenti. Il primo può comprendere analisi, sviluppo, test, documentazione e un periodo definito di correzione. Il secondo può concentrare quasi tutto sulla programmazione e fatturare separatamente progettazione, pubblicazione e assistenza. Il totale iniziale coincide; il costo dei primi 24 mesi probabilmente no.

Conta anche il modello contrattuale.

  • Prezzo fisso: tutela il budget soltanto se funzioni, esclusioni e collaudo sono descritti bene. Ogni ambiguità può trasformarsi in una variante a pagamento.
  • Pagamento a tempo: remunera le ore o le giornate impiegate. È flessibile quando i requisiti cambiano, ma richiede controllo frequente di priorità e spesa.
  • Canone continuativo: distribuisce il costo e può comprendere assistenza, monitoraggio o un monte di attività. Bisogna verificare che cosa accade alle ore non usate e agli interventi oltre soglia.
  • Modello misto: prevede una parte fissa per la prima versione e una quota periodica per gestione ed evoluzione. Le due aree devono restare separate nel contratto.

Va controllata anche l’uscita dal rapporto. Codice, credenziali, configurazioni, documentazione e copie dei dati devono essere elencati tra i materiali consegnati. In caso contrario, cambiare fornitore può richiedere attività tecniche non considerate nel preventivo iniziale.

Accessibilità, conformità e ritorno economico vanno calcolati prima

L’accessibilità riguarda la possibilità di usare l’applicazione anche con esigenze e modalità di interazione differenti. La conformità comprende i requisiti organizzativi, tecnici o contrattuali applicabili al progetto. Non sono una spunta finale.

Queste attività possono richiedere analisi iniziale, scelte di interfaccia, struttura corretta dei contenuti, verifiche, correzioni e documentazione. Il preventivo deve dire quali requisiti vengono considerati, come saranno provati e chi approva il risultato. Una formula generica come “a norma” non definisce né il lavoro né la responsabilità.

Per valutare il ritorno sull’investimento bisogna confrontare il costo totale di possesso con un risultato misurabile. Il conto dei 24 mesi comprende sviluppo iniziale, canoni, infrastruttura, manutenzione, aggiornamenti, formazione e gestione delle emergenze.

I benefici possono essere stimati partendo da dati aziendali già osservabili:

  • tempo impiegato oggi per completare ogni pratica;
  • numero di operazioni ripetitive che l’applicazione può ridurre;
  • errori e rilavorazioni registrati;
  • ordini o richieste persi per procedure lente;
  • costi dei programmi che saranno sostituiti.

La formula di base è: benefici economici dei 24 mesi meno costo totale dei 24 mesi, diviso per il costo totale. Se i benefici dipendono da ipotesi, vanno scritte. Senza quantità iniziali e obiettivi verificabili, il ritorno promesso resta una previsione senza riscontro.

Le domande da inserire nel capitolato

Area Domanda da scrivere Che cosa evita
Analisi Quali requisiti, percorsi utente e prototipi saranno consegnati? Decisioni rinviate allo sviluppo
Funzioni Quali operazioni sono incluse per ogni profilo utente? Richieste aggiuntive impreviste
Collaudo Con quali prove una funzione viene considerata accettata? Discussioni sulla consegna
Infrastruttura Quali risorse, backup e servizi gestiti sono compresi? Canoni tecnici non dichiarati
Monitoraggio Quali controlli vengono eseguiti e chi riceve gli avvisi? Problemi scoperti dagli utenti
Manutenzione Che differenza c’è tra difetto, modifica ed emergenza? Fatture contestate
Assistenza Quali tempi di risposta e intervento sono previsti? Attese indefinite
Accessibilità Quali requisiti e verifiche sono compresi? Correzioni tardive
Uscita Quali codice, dati, credenziali e documenti saranno consegnati? Dipendenza dal fornitore
Costi Qual è la stima separata per mesi 0, 4, 12 e 24? Confronti limitati al prezzo iniziale

La mossa pratica è chiedere a ogni fornitore lo stesso prospetto dei primi 24 mesi. Il totale viene dopo. Prima bisogna verificare quali attività comprende, quali rischi lascia al cliente e quanto costa mantenere l’applicazione realmente utilizzabile.

Da leggere anche: Varie ed eventuali nei verbali: il caso della spesa approvata a sorpresa

Da leggere anche: Web designer: quanto costa davvero e quali voci cambiano il preventivo

Da leggere anche: Web cam: checklist per risoluzione, microfono, privacy e compatibilità