Chi sviluppa un SaaS costruisce tre cose insieme: il software che risolve un problema, il sistema che lo vende in abbonamento e il servizio che lo tiene acceso, sicuro e aggiornato per tutti i clienti nello stesso momento. Si parte verificando che il problema esista e che qualcuno paghi per risolverlo, poi si costruisce una prima versione con i dati dei clienti ben separati tra loro, e solo dopo si allarga. Il codice è la parte più visibile, non la più rischiosa.
Cosa rende un software un SaaS?
Il NIST, l'ente statunitense per gli standard, descrive così il modello SaaS: il cliente usa un'applicazione del fornitore che gira su un'infrastruttura cloud, la apre dal browser o tramite interfacce di programmazione, e non gestisce server, reti o sistemi operativi, salvo qualche impostazione personale. Nella stessa definizione le risorse del fornitore servono più clienti insieme, con un modello multi-tenant (NIST SP 800-145).
Per chi lo costruisce, questo ha tre conseguenze pratiche. Tutti i clienti usano la stessa versione, quindi ogni personalizzazione chiesta da uno pesa su tutti. Sei tu a rispondere di disponibilità, aggiornamenti e sicurezza, anche di notte e ad agosto. E incassi un po' alla volta: il progetto si ripaga solo se i clienti restano.
Da dove si parte, prima di scrivere codice?
Dal problema e da chi paga per risolverlo. Parla con persone del tuo pubblico, guarda come lavorano oggi, cerca chi ci ha già provato con fogli di calcolo o strumenti adattati. Se esistono concorrenti è una buona notizia: vuol dire che qualcuno paga per quel problema, e le recensioni dei loro clienti ti dicono cosa manca.
Il segnale più forte è un impegno economico: una preiscrizione a pagamento, una lettera d'intenti, un cliente pilota che accetta un canone ridotto in cambio del suo tempo e dei suoi commenti. Iscrizioni gratuite e complimenti contano molto meno. Come trasformare l'ipotesi in una prima versione con il perimetro giusto lo spieghiamo nella guida allo sviluppo di un MVP.
Come si tengono separati i dati dei clienti?
È una delle scelte tecniche più delicate, perché cambiarla dopo costa molto. I modelli principali sono tre:
- Un database per ogni cliente: il massimo isolamento, ma tanti database da aggiornare, controllare e salvare man mano che i clienti crescono.
- Uno schema per cliente dentro lo stesso database: un compromesso tra isolamento e semplicità di gestione.
- Tabelle condivise con l'identificativo del cliente su ogni riga: il modello più efficiente, che però richiede regole di accesso applicate senza eccezioni.
Con PostgreSQL il terzo modello si può rafforzare con la Row Level Security: regole scritte nel database che decidono, per ogni utente, quali righe può leggere o modificare. Se la protezione è attiva e per una tabella manca una regola, il database non mostra nulla; i superutenti e, di norma, il proprietario della tabella però la scavalcano, e va tenuto presente quando si configura l'applicazione (PostgreSQL, Row Security Policies).
Non è un dettaglio da sviluppatori. Nella OWASP Top 10:2025 il controllo degli accessi difettoso è il rischio numero uno delle applicazioni web (OWASP), e in un SaaS significa un cliente che vede i dati di un altro. Chiedi a chi sviluppa come sono isolati i dati e con quali test automatici verifica che un utente non possa leggere quelli altrui.
Con quale tecnologia conviene costruirlo?
Con una tecnologia noiosa, nel senso buono: diffusa, documentata, conosciuta da tanti sviluppatori. Noi per l'interfaccia lavoriamo con Next.js e React, ma qualunque sia la scelta contano tre criteri, e nessuno riguarda la moda del momento.
- Continuità: tra qualche anno dovrai trovare persone capaci di mettere le mani sul codice, anche se chi l'ha scritto non c'è più.
- Servizi specializzati per le parti che non ti distinguono: pagamenti, invio di email, accesso degli utenti. Si integrano, non si riscrivono da zero.
- Posizione dei dati: se finiscono su server fuori dall'Unione europea, il GDPR chiede che il trasferimento rispetti condizioni specifiche (GDPR, capo V). Meglio saperlo prima di scegliere i fornitori.
Abbonamenti, prove gratuite e fatture: cosa va costruito?
Anche la parte commerciale di un SaaS è software. Piattaforme come Stripe gestiscono il ciclo di vita dell'abbonamento: generano le fatture, tentano l'incasso, riprovano quando un pagamento non va a buon fine e aggiornano lo stato dell'abbonamento, anche durante un periodo di prova. La tua applicazione riceve questi cambi di stato tramite webhook e apre o chiude l'accesso di conseguenza (Stripe, come funzionano gli abbonamenti).
Restano da progettare i piani, cioè cosa include ciascuno e con quali limiti, i passaggi da un piano all'altro, le disdette e cosa succede ai dati di chi se ne va. In Italia c'è un passaggio in più: tra soggetti residenti o stabiliti nel Paese le fatture sono solo elettroniche, sia verso aziende sia verso consumatori (Agenzia delle Entrate), e viaggiano attraverso il Sistema di Interscambio (Agenzia delle Entrate, SdI). Il flusso che incassa l'abbonamento deve quindi parlare con quello che emette la fattura.
Quali responsabilità ti prendi verso i clienti?
Se vendi ad aziende, di solito tratti dati personali per loro conto: nel linguaggio del GDPR sei il responsabile del trattamento. Serve un contratto con i contenuti previsti dall'articolo 28, e non puoi affidare parte del trattamento ad altri fornitori, come l'hosting o il servizio che spedisce le email, senza la loro autorizzazione scritta, specifica o generale (art. 28 GDPR).
Poi c'è la sicurezza: misure adeguate al rischio, capacità di ripristinare i dati dopo un incidente, verifiche periodiche. Se qualcosa va storto devi avvisare il cliente senza ingiustificato ritardo, perché sarà lui a dover notificare la violazione al Garante, ove possibile entro 72 ore (artt. 32 e 33 GDPR). Backup provati, registri delle operazioni e una procedura per gli incidenti vanno quindi preparati prima dei primi clienti. Le basi le trovi nella guida alla sicurezza del sito web.
Quali sono le fasi, dallo sketch al lancio?
- Validazione: interviste, studio dei concorrenti, primi impegni economici.
- Analisi: flussi principali, ruoli, dati trattati, integrazioni, modello di separazione dei dati.
- Design: prototipo delle schermate chiave e un piccolo sistema di componenti riusabili, provato con qualche utente.
- Prima versione: registrazione e accesso, primo utilizzo guidato, abbonamento, pannello interno per il tuo team e le due o tre funzioni che fanno la differenza.
- Beta privata: pochi clienti veri, meglio se paganti, seguiti da vicino.
- Lancio pubblico: pagine pubbliche, documentazione, assistenza, monitoraggio degli errori.
- Iterazione: rilasci frequenti guidati dai dati d'uso e dalle conversazioni con i clienti.
Quanto pesa ogni fase dipende dal perimetro, dalle integrazioni e dalla velocità con cui si prendono le decisioni. Quello che accorcia il percorso è tagliare funzioni, non saltare la beta.
Dopo il lancio: cosa cambia e chi porta avanti il prodotto?
Dopo il lancio contano soprattutto due numeri: quanto incassi ogni mese dagli abbonamenti attivi, il ricavo ricorrente mensile, e quanti clienti perdi nello stesso periodo, il tasso di abbandono. Se l'abbandono è alto, portare nuovi clienti è come riempire un secchio bucato: prima si capisce perché le persone se ne vanno, poi si accelera.
Il lavoro quotidiano diventa un ciclo: guardare come viene usato il prodotto, parlare con chi lo usa e con chi lo lascia, rilasciare miglioramenti piccoli e frequenti, rispondere all'assistenza. Per Athleex, SaaS per personal trainer e atleti, abbiamo curato tutta la presenza digitale del prodotto: il marchio, la web app installabile come PWA, il sito multilingua con la SEO e i contenuti del blog.
Poi c'è la domanda su chi lo sviluppa nel tempo. Un team interno conosce il prodotto meglio di chiunque, ma va assunto, coordinato e tenuto occupato anche nei mesi più tranquilli. Un partner esterno porta da subito competenze diverse, dal design al backend alla SEO, ed è utile soprattutto all'inizio, a patto che codice, account e documentazione restino intestati a te. C'è anche una strada mista: si parte con un partner e si porta il lavoro in casa un po' alla volta. Se sei in fase di avvio, trovi i criteri per scegliere nella guida all'agenzia web per startup.
Le scelte che contano in un SaaS si fanno prima della prima riga di codice: dati, piani, perimetro. Possiamo farle insieme a te, partendo dalla pagina sviluppo web app.
Domande frequenti
Quanto costa sviluppare un SaaS?
Dipende dal perimetro della prima versione, dalle integrazioni, dal modello di separazione dei dati, dalla complessità degli abbonamenti e dal livello di design. A questo si aggiungono i costi di esercizio che continuano dopo il lancio, come hosting, servizi email, commissioni sui pagamenti e assistenza. Chiedi un preventivo che separi lo sviluppo dai costi ricorrenti.
Serve per forza un'app per smartphone?
No. Molti SaaS nascono come web app usabili da computer e da telefono; se servono l'icona sulla schermata Home o le notifiche, si può rendere installabile come PWA. Le app native si valutano dopo, quando l'uso da telefono diventa centrale per i clienti.
Posso personalizzare il SaaS per un cliente importante?
Si può, con cautela: ogni personalizzazione vive nella stessa base di codice usata da tutti gli altri clienti. Conviene trasformarla in un'impostazione attivabile, utile anche ad altri, invece di creare un ramo separato del prodotto che poi va mantenuto a parte.
Il SaaS deve rispettare il GDPR già al lancio?
Sì, dal primo cliente che inserisce dati personali. Servono il contratto sul trattamento dei dati con i clienti, l'elenco dei fornitori che trattano dati per tuo conto, misure di sicurezza adeguate e una procedura per gestire eventuali violazioni.
