La domanda sbagliata arriva per prima
"Dobbiamo costruire un sito web o un'app?" è la domanda che riceviamo in quasi ogni prima chiamata. È la domanda sbagliata. Salta un passaggio.
La domanda giusta è: cosa deve fare questo prodotto, e per chi? Un sito vetrina, una web app su misura e una Progressive Web App (PWA) risolvono problemi diversi. Scegliere quello sbagliato non spreca solo budget — ti blocca in un'architettura costosa da smontare sei mesi dopo, di solito subito dopo il primo giro di feedback reale degli utenti.
Ecco il framework che usiamo con i clienti prima ancora di scrivere una singola riga di codice, insieme a range onesti su quanto costa ciascuna opzione e quanto tempo richiede nel 2026.
Tre lavori diversi, non tre livelli dello stesso lavoro
I team li trattano come una scala — sito vetrina in basso, PWA in cima, app nel mezzo. Non è corretto. Non sono versioni più o meno sofisticate l'una dell'altra. Rispondono a domande diverse.
Sito vetrina. Compito: convertire un visitatore in un contatto o in una vendita. Guidato dai contenuti, per lo più pubblico, senza account utente (o con uno minimale aggiunto per i contenuti riservati). Il successo si misura in tasso di conversione, velocità di caricamento e posizionamento sui motori di ricerca. Costruito su un CMS o un framework per siti statici, raramente con logica backend personalizzata oltre a form e analytics.
Web app su misura. Compito: permettere a un utente autenticato di svolgere un lavoro reale — gestire l'inventario, revisionare pratiche, prenotare appuntamenti, generare report. È qui che vive la logica di business: permessi, workflow, validazione dei dati, integrazioni con il tuo CRM o ERP. Il successo si misura in tempo di completamento delle attività e tasso di errore, non in visualizzazioni di pagina.
PWA. Compito: dare a una web app la sensazione di un'app nativa — icona installabile, accesso offline alle schermate chiave, notifiche push — senza il ciclo di revisione dell'App Store o due codebase separate. Non è tanto una quarta categoria quanto una modalità di distribuzione applicata sopra una web app. Non costruisci "una PWA" al posto di una web app; costruisci una web app e decidi quanta parte del livello PWA (service worker, cache offline, prompt di installazione) vale la pena aggiungere.
Come scegliere davvero
Fatti queste quattro domande, in ordine:
- Un utente effettua il login e svolge un lavoro ripetibile, oppure un visitatore legge e se ne va? Lavoro ripetibile → web app. Legge e se ne va → sito vetrina.
- Il prodotto deve funzionare con una connessione instabile, su smartphone, lontano da una scrivania? Tecnici sul campo, personale di magazzino, corrieri — sì. Lavoratori d'ufficio con una connessione stabile — di solito no, e il livello PWA è un costo aggiuntivo di cui non hai ancora bisogno.
- La visibilità sui motori di ricerca fa parte del modo in cui le persone ti trovano? Se sì, quel contenuto deve vivere su un sito vetrina veloce e indicizzabile — non sepolto dietro il login della tua app — e deve avere le basi tecniche (i fondamentali SEO: contenuto renderizzato lato server, URL puliti, schema funzionante) integrate fin dal primo commit, non aggiunte dopo il lancio.
- Ti servono entrambi? Alla maggior parte delle aziende B2B sì: un sito vetrina per generare il contatto, e una web app dietro il login dove il cliente pagante vive davvero. Sono due progetti, non uno — e trattarli come un unico progetto è un motivo comune per cui i progetti web sforano il budget iniziale.
Se stai costruendo il secondo tipo — l'app che i tuoi clienti usano davvero — è lì che il nostro team di sviluppo web passa la maggior parte del tempo, perché è lì che si concentrano davvero costi e rischi.
Cosa determina davvero i costi
Il costo non dipende principalmente dal numero di pagine o da "quante funzionalità". Dipende da quattro fattori:
Complessità del modello dati. Un'app CRUD con una manciata di tipi di entità semplici è un progetto diverso da uno con permessi basati sui ruoli su molti tipi di entità con audit trail. Ogni relazione aggiunta moltiplica la superficie di test, non solo lo schema.
Integrazioni. Ogni sistema di terze parti a cui ti colleghi — Stripe, Salesforce, l'API di un corriere, un database legacy interno — aggiunge tempo reale a seconda di quanto è documentata e stabile l'API di quel sistema. I sistemi interni non documentati sono una delle maggiori fonti di slittamento dei tempi che vediamo, perché non scopri i casi limite finché non sei già a integrazione avviata.
Requisiti real-time e offline. Una dashboard che si aggiorna al caricamento della pagina costa poco. Una dashboard con aggiornamenti live via websocket, o una vista mobile che deve funzionare senza connessione e sincronizzarsi dopo, aggiunge tempo di ingegneria reale oltre alla base di sviluppo per le schermate coinvolte.
Maturità del design. Se parti da un file Figma con ogni stato (vuoto, caricamento, errore, caso limite) già progettato, lo sviluppo procede veloce. Se il design avviene in parallelo allo sviluppo, aspettati del rework — le schermate vengono costruite su una specifica che cambia sotto di loro.
L'esperienza del team e la sua sede influenzano la tariffa oraria, ma raramente spiegano le oscillazioni più grandi nel costo totale del progetto. Sono i quattro fattori sopra a farlo.
Tempistiche realistiche per il 2026
Questi sono range approssimativi per un singolo progetto ben definito — non un intero portfolio di tutto ciò di cui una grande azienda potrebbe aver bisogno — basati su progetti che abbiamo definito di recente:
- Sito vetrina (una manciata di pagine, basato su CMS, senza backend personalizzato): qualche settimana.
- Web app su misura, complessità standard (autenticazione, alcuni tipi di entità principali, una o due integrazioni): circa un trimestre.
- Web app su misura, alta complessità (permessi multi-ruolo, diverse integrazioni, funzionalità real-time): un paio di trimestri o più.
- Aggiungere il livello PWA a una web app esistente (cache offline per le schermate chiave, prompt di installazione, push): qualche settimana, a seconda di quanta parte dell'app deve funzionare offline rispetto al semplice essere installabile.
Chiunque ti dia un numero fisso senza chiederti del tuo modello dati, delle tue integrazioni e dello stato del design sta tirando a indovinare.
Lo schema che vediamo più spesso
L'errore più comune non è scegliere il formato sbagliato — è sceglierne uno e chiedergli di svolgere entrambi i compiti. Un'azienda costruisce un sito vetrina curato, poi cerca di aggiungere una dashboard cliente sulla stessa codebase perché "è già costruita". Mesi dopo la dashboard sta litigando con il CMS per il controllo del routing, e ogni aggiornamento dei contenuti rischia di rompere una funzionalità riservata agli utenti loggati.
La soluzione è quasi sempre separarli fin dall'inizio: un sito vetrina leggero ottimizzato per velocità e ricerca, e una web app separata ottimizzata per l'esperienza da loggati, che condividono un design system ma non una codebase. Costa leggermente di più all'inizio. Evita una ricostruzione in seguito.
In sintesi
Non partire da "sito web o app". Parti da cosa sta facendo l'utente e da quanto di questo deve resistere a una connessione scadente. Tratta il sito vetrina e il prodotto riservato agli utenti loggati come due decisioni separate, anche se è un unico team a costruire entrambi. E quando fai un preventivo per un progetto su misura, chiedi del modello dati e delle integrazioni prima di chiedere il numero di pagine — è da lì che arriva il numero vero.
Se sei al punto di dover definire uno di questi progetti e vuoi una risposta diretta su costi e tempistiche per il tuo caso specifico, parlane con noi prima di scrivere l'RFP.
