Un sito web serve a farti trovare e a spiegare chi sei: mostra gli stessi contenuti a chiunque lo visiti e il suo lavoro finisce quando qualcuno ti contatta. Una web app è un software che si usa dal browser: le persone entrano con un account, inseriscono dati e ognuna vede cose diverse in base al proprio ruolo. Per capire quale ti serve, chiediti cosa devono fare le persone: leggere e scriverti, oppure lavorare con i propri dati.
Che differenza c'è tra sito web e web app, in pratica?
Il sito è fatto di pagine uguali per tutti: la home, i servizi, il blog, le schede prodotto, una landing per una campagna. Chi arriva legge, confronta, poi chiama o compila un modulo. Lo misuri con le visite, le richieste di contatto, le prenotazioni. Anche la documentazione di Next.js, il framework con cui lavoriamo, divide le cose così: le pagine con dati condivisi da tutti, come un articolo o una scheda prodotto, si preparano in anticipo, mentre una dashboard con dati personali si genera al momento per ogni utente (Next.js, rendering statico e dinamico).
La web app, invece, è uno strumento di lavoro: un gestionale degli ordini, un'area clienti con documenti e fatture, un portale per i rivenditori, un CRM costruito sul modo in cui lavora la tua azienda. Per KEY srl abbiamo sviluppato un CRM interno multi-account: ogni consulente gestisce le proprie pratiche con il suo account, mentre la direzione ha una vista unica su tutti i flussi. Per Rial Rent abbiamo costruito un CRM gestionale con automazioni che smistano le richieste di noleggio, avvisano il team e tengono traccia dello stato di ogni pratica.
Web app, app da scaricare e PWA sono la stessa cosa?
No, e la confusione nasce dal nome. La web app si apre nel browser, da computer o da telefono, senza passare dagli store. L'app nativa si scarica da App Store o Google Play ed è scritta per quel sistema operativo. In mezzo c'è la PWA, una web app che si può installare sul dispositivo, aprire come un'app e usare anche quando la rete manca (MDN, Progressive web apps).
Per molti strumenti aziendali la web app classica basta: i dipendenti la aprono dal computer in ufficio e dal telefono in magazzino, e ogni aggiornamento arriva a tutti nello stesso momento. Quando conviene renderla installabile lo spieghiamo nella guida alle PWA.
Quali segnali dicono che ti serve una web app?
Se ti riconosci in almeno uno di questi punti, stai descrivendo un'applicazione, anche se la chiami sito:
- Persone diverse devono vedere dati diversi: il cliente solo i suoi ordini, l'agente solo i suoi clienti, il titolare tutto.
- Un processo oggi vive tra fogli Excel condivisi, email e telefonate, e qualcuno ricopia gli stessi dati in più posti.
- Devi dare accesso a persone esterne, come clienti, fornitori o rivenditori, con permessi diversi.
- Ti serve sapere chi ha modificato cosa e quando.
- I dati devono passare in automatico da e verso altri software: gestionale, fatturazione, magazzino, calendario.
- Il valore sta in quello che le persone fanno dopo l'accesso, non in quello che leggono prima.
Se invece l'obiettivo è farti trovare, presentare l'azienda e raccogliere richieste, ti serve un sito. Un buon modulo di contatto, un sistema di prenotazione già pronto o un catalogo ben fatto coprono molte esigenze che all'inizio sembrano da applicazione.
Una web app porta clienti da Google come un sito?
Da sola no. Quello che sta dietro un login resta fuori dalla Ricerca: Google stesso indica la protezione con password come il modo per tenere i contenuti riservati lontani dai risultati (Google Search Central). Il gestionale più curato non porta visite, perché nessuno può vederlo senza credenziali.
Se ti servono anche nuovi contatti, ti servono pagine pubbliche: un sito, oppure la parte pubblica della piattaforma, con pagine che spiegano il prodotto e rispondono alle ricerche delle persone. Per queste pagine vale tutto quello che vale per un sito: contenuti utili, velocità, struttura chiara. È il lavoro che facciamo nella realizzazione di siti web.
Si possono avere sito pubblico e area riservata nello stesso progetto?
Sì, ed è quello che di solito si intende con la parola portale: pagine pubbliche, trovabili su Google, più un'area dove clienti, rivenditori o fornitori entrano con le proprie credenziali e trovano i propri dati.
Con Next.js le due parti possono vivere nella stessa base di codice: pagine pubbliche preparate in anticipo, veloci e facili da indicizzare, e sezioni riservate generate per ogni utente dopo il controllo degli accessi. La documentazione del framework divide questo controllo in tre lavori distinti: verificare chi è l'utente, mantenere la sua sessione e decidere a quali pagine e dati può accedere (Next.js, autenticazione).
Il vantaggio di un progetto unico è che mantieni una sola base di codice e riusi gli stessi componenti grafici. Il limite è che ogni rilascio tocca entrambe le parti: quando l'applicazione cresce molto, a volte conviene spostarla su un sottodominio con un ciclo di aggiornamenti tutto suo.
Cosa cambia in impegno, sicurezza e manutenzione?
Un sito chiede cura dei contenuti, velocità, aggiornamenti e backup. Una web app aggiunge un database, gli account, i permessi, i registri delle operazioni, i backup da provare con un ripristino vero e l'aggiornamento continuo delle librerie su cui poggia. E aggiunge obblighi: se tratti dati personali, il GDPR chiede misure di sicurezza adeguate al rischio, tra cui la capacità di ripristinare i dati dopo un incidente e verifiche regolari della loro efficacia (art. 32 GDPR).
La parte più delicata sono i permessi. Nella OWASP Top 10:2025, la classifica dei rischi delle applicazioni web, il controllo degli accessi difettoso è al primo posto, e l'OWASP lo ha trovato in qualche forma nel 100% delle applicazioni testate (OWASP, A01:2025). Per questo una web app non si confronta con un sito contando le pagine: si confronta su ruoli, dati, integrazioni e responsabilità.
Se vuoi farti un'idea dell'impegno prima di chiedere un preventivo, prepara quattro risposte: quanti tipi di utente ci sono e cosa può fare ciascuno, quali software devono scambiare dati con l'applicazione, quali dati personali tratterai, da quali dispositivi verrà usata. Sono le voci che spostano di più il perimetro del lavoro.
Quali errori costano di più quando si sceglie?
Il primo è costruire un'applicazione quando bastava un sito: un'area riservata che nessuno apre, un configuratore complicato dove sarebbe servita una telefonata. Prima di sviluppare, verifica che il processo esista davvero e che le persone lo farebbero online.
Il secondo è l'opposto: aggiungere funzioni da applicazione a un sito vetrina un plugin alla volta, finché ogni aggiornamento rompe qualcosa. Se il sito deve gestire utenti, stati e permessi, conviene progettarlo come applicazione fin dall'inizio.
Il terzo è aspettarsi che la web app porti clienti. L'applicazione fa lavorare meglio chi è già dentro, mentre per farti trovare servono pagine pubbliche e un lavoro dedicato alla visibilità.
Come si decide, in pratica?
Parti dal processo, non dalla tecnologia. Scrivi chi userà lo strumento, cosa deve fare e in che ordine, quali dati tocca e cosa succede quando ha finito. Se la risposta è «legge, poi ci scrive», ti serve un sito. Se è «entra, lavora, salva, e un collega riprende da dove ha lasciato», ti serve una web app. Se sono vere entrambe, ti servono tutte e due, e conviene progettarle insieme.
Tre situazioni tipiche, descritte come esempi:
- Uno studio di consulenza che vuole nuovi clienti: gli serve un sito, con una pagina per ogni servizio, articoli che rispondono alle domande dei clienti e un modulo di contatto.
- Un distributore che vende a negozi e rivenditori: gli servono un sito pubblico con il catalogo e un'area riservata dove ogni rivenditore vede i suoi listini e ordina, cioè il classico portale.
- Un'azienda di assistenza con i tecnici sempre in giro: le serve una web app per assegnare gli interventi, compilare i rapporti dal telefono e chiudere le pratiche, magari installabile per lavorare anche dove la rete è debole.
Se hai un processo che oggi passa da email e fogli di calcolo e vuoi capire se diventerà un'applicazione, un sito o entrambi, partiamo proprio da lì: nella pagina sviluppo web app trovi come progettiamo le applicazioni su misura.
Domande frequenti
Una web app costa più di un sito web?
Di solito sì, perché oltre alle pagine servono database, account, permessi, sicurezza e una manutenzione che non si ferma al lancio. L'impegno dipende soprattutto dal numero di ruoli, dalle integrazioni con altri software e dai dati personali trattati. Per confrontare due preventivi, controlla che entrambi descrivano queste voci e cosa è incluso dopo il rilascio.
Posso aggiungere un'area riservata al sito che ho già?
Sì: il sito resta com'è e si aggiunge una sezione con accesso. Prima conviene decidere dove vivranno i dati, chi gestirà gli account e come l'area si collegherà agli altri strumenti aziendali. Un'area riservata costruita con plugin sopra un sito vetrina regge finché i permessi restano semplici.
Una web app funziona anche da smartphone?
Sì, se è progettata anche per schermi piccoli: si apre dal browser del telefono come qualsiasi pagina. Se servono l'icona sulla schermata Home, l'uso con rete scarsa o le notifiche, si può rendere installabile come PWA. In molti casi questo evita di sviluppare due app separate per gli store.
Un portale clienti con documenti da scaricare è un sito o una web app?
È una piccola web app, anche se vive dentro il sito. Ogni cliente accede con le proprie credenziali e vede solo i propri documenti, quindi servono account, permessi e protezione dei dati personali. Le pagine pubbliche restano sito, la parte riservata è applicazione.
