Architettura SaaS: Cosa Devono Sapere i Fondatori Non Tecnici Prima di Costruire

Esiste un tipo specifico di rimpianto che colpisce i fondatori di SaaS circa diciotto mesi dopo l'avvio del progetto. Il prodotto è live, i primi clienti lo stanno utilizzando, e a un certo punto qualcuno dice: "Prima di poter fare X, dovremmo ridisegnare l'architettura della gestione dei tenant." Oppure: "Il sistema di fatturazione non è stato costruito per la tariffazione basata sull'utilizzo — ci vorranno tre mesi per rifarlo." O, nel peggiore dei casi: "Quel requisito di conformità implica che abbiamo bisogno di un isolamento dei dati per cliente, ma l'intero sistema condivide un unico database."

Non si tratta di bug. Sono scelte architetturali che sembravano ragionevoli all'inizio e che ora sono molto costose da correggere.

Il motivo per cui questo accade così spesso non è la negligenza degli sviluppatori. È che i fondatori non avevano abbastanza contesto per porre le domande giuste prima che il progetto iniziasse — e così il team di sviluppo ha optato per ciò che era più veloce, più semplice o più familiare, anziché per ciò che era più appropriato rispetto alla direzione che il prodotto avrebbe dovuto prendere.

Non è necessario diventare un software architect. Ma è necessario avere una comprensione sufficiente delle principali decisioni architetturali di un prodotto SaaS per partecipare alla conversazione, mettere in discussione le assunzioni e prendere decisioni informate. È questo lo scopo di questa guida.

---

Cos'è l'Architettura SaaS?

Con architettura SaaS si intende l'insieme delle decisioni di progettazione che determinano come un prodotto software viene costruito, ospitato e mantenuto, in modo da poter servire più clienti simultaneamente, gestire abbonamenti e fatturazione in modo automatico, onboardare gli utenti senza intervento manuale e scalare senza richiedere una ricostruzione completa.

Un prodotto SaaS ben progettato presenta cinque proprietà fondamentali:

• Multi-tenancy — più clienti (tenant) condividono la stessa infrastruttura applicativa, con i loro dati mantenuti in modo adeguatamente separato
• Fatturazione ad abbonamento — i clienti pagano su base ricorrente e il sistema di fatturazione gestisce automaticamente i piani, le prove, gli aggiornamenti, i downgrade e i rinnovi
• Onboarding self-service — gli utenti possono registrarsi, configurare il proprio account e iniziare a utilizzare il prodotto senza che sia necessario l'intervento di una persona dal vostro lato
• Design API-first — il nucleo del prodotto è esposto tramite un'API ben strutturata che supporta integrazioni, applicazioni mobile e future estensioni
• Infrastruttura cloud — il prodotto risiede su un'infrastruttura cloud che può scalare verso l'alto o verso il basso in base alla domanda, anziché su server fissi

Queste non sono funzionalità separate da aggiungere in seguito. Sono proprietà architetturali — o progettate fin dall'inizio, o aggiunte dolorosamente in un secondo momento. Le decisioni che determinano se il vostro prodotto possiede queste proprietà vengono prese nelle prime settimane del progetto.

---

Multi-Tenancy: La Decisione Più Importante

La multi-tenancy è la caratteristica architettuale distintiva del SaaS. È anche la decisione dalle conseguenze più ampie — per la struttura dei costi, il posizionamento rispetto alla conformità, la capacità di personalizzare per i clienti enterprise e la complessità del codice.

Esistono tre modelli principali:

Il Modello Pool (Condivisione Totale)

In un'architettura a pool, tutti i clienti condividono un unico database (e spesso un'unica istanza applicativa). I loro dati sono separati da una colonna tenant ID in ogni tabella del database. Una riga appartiene all'Azienda A, la successiva all'Azienda B, e così via — tutte nella stessa tabella.

Vantaggi: Il meno costoso da gestire. Il più semplice da costruire inizialmente. L'infrastruttura del database scala una sola volta anziché una volta per cliente. I deployment e gli aggiornamenti avvengono in un unico punto.

Svantaggi: Una query mal configurata può esporre i dati di un tenant a un altro. I framework di conformità che richiedono l'isolamento dei dati (SOC 2, ISO 27001, alcuni requisiti sanitari) sono più difficili da soddisfare. I problemi di "vicino rumoroso" sono reali — un tenant che esegue una query pesante può influire su tutti gli altri. Le configurazioni personalizzate per singolo tenant diventano complicate.

Il Modello Silo (Isolamento Totale)

In un'architettura a silo, ogni cliente dispone della propria infrastruttura isolata — la propria istanza database, talvolta il proprio ambiente applicativo. I loro dati non entrano mai in contatto con i dati di un altro tenant a livello infrastrutturale.

Vantaggi: Vero isolamento dei dati by design. Più facile soddisfare i requisiti di conformità enterprise. Un problema nell'ambiente di un tenant non può influire sugli altri. È possibile eseguire versioni diverse del prodotto per diversi clienti enterprise.

Svantaggi: Significativamente più costoso da gestire su scala. La gestione di centinaia di istanze database è operativamente complessa. I deployment e gli aggiornamenti devono essere coordinati in tutti gli ambienti silo. Difficile eseguire analisi cross-tenant sui propri dati di utilizzo.

Il Modello Bridge (App Condivisa, Schemi Separati)

Il modello bridge si colloca tra i due. Tutti i tenant utilizzano lo stesso livello applicativo, ma ogni tenant dispone di uno schema database separato (o in alcune implementazioni, di un database separato all'interno di un cluster condiviso). I dati sono fisicamente separati senza il pieno overhead operativo del modello silo.

Vantaggi: Migliore isolamento dei dati rispetto al modello pool. Più semplice da gestire rispetto ai silo completi. Funziona bene per clienti mid-market ed enterprise con requisiti di conformità moderati.

Svantaggi: Più complesso da costruire rispetto al modello pool puro. La gestione delle migrazioni del database diventa più difficile — si esegue la stessa migrazione su molti schemi. Alcuni strumenti non gestiscono in modo elegante le configurazioni multi-schema.

Modello	Costo Infrastrutturale	Isolamento Dati	Idoneità alla Conformità	Complessità Operativa
Pool (DB Condiviso)	Basso	Solo logico	Base	Bassa
Bridge (App Condivisa, Schemi Separati)	Medio	Fisico per tenant	Mid-market/Enterprise	Media
Silo (Isolato)	Alto	Isolamento completo	Enterprise/Regolamentato	Alta

La risposta giusta dipende dal vostro mercato. Se vendete a PMI e non prevedete clienti enterprise in settori regolamentati, un modello pool ben implementato è del tutto sensato. Se la vostra roadmap prevede la vendita a servizi finanziari, sanità o grandi aziende con questionari di sicurezza, la risposta è quasi certamente un approccio bridge o silo — e il costo dell'aggiunta dell'isolamento in un secondo momento è enorme.

Questa è una decisione che deve essere presa prima che venga scritta una sola riga di codice.

---

Autenticazione e Identità

L'autenticazione — verificare l'identità di un utente — sembra un problema risolto. Si aggiunge un modulo di login, si applicano hash alle password, e il gioco è fatto. In un'app consumer, potrebbe essere così. In un prodotto SaaS, è considerevolmente più complesso.

Un prodotto SaaS in produzione deve gestire:

• Autenticazione con nome utente e password con archiviazione sicura, flussi di reimpostazione della password e protezione contro gli attacchi brute-force
• OAuth / social login (Google, Microsoft, GitHub) — che gli utenti si aspettano sempre di più
• Autenticazione a più fattori (MFA) — attesa da qualsiasi acquirente enterprise e richiesta da molti framework di conformità
• Single Sign-On (SSO) tramite SAML 2.0 o OIDC — richiesto da quasi ogni cliente enterprise oltre una certa dimensione, spesso come requisito di acquisto non negoziabile
• Inviti al team — un utente che invita altri al proprio account, con assegnazione dei ruoli
• Controllo degli accessi basato sui ruoli (RBAC) — gli amministratori vedono tutto, i visualizzatori vedono solo ciò che devono, e tutto ciò che si trova nel mezzo
• Gestione delle sessioni — mantenere le sessioni attive in modo appropriato, gestire le sessioni simultanee, disconnessione forzata al cambio della password
• Audit logging degli eventi di autenticazione — chi ha effettuato l'accesso, da dove, quando e cosa ha fatto

Costruire tutto questo da zero è costoso e introduce un rischio di sicurezza reale. Ogni implementazione di autenticazione personalizzata ha il potenziale di introdurre vulnerabilità che i sistemi dedicati hanno già risolto.

La nostra raccomandazione predefinita è di utilizzare una piattaforma di gestione delle identità — Auth0, Clerk o Supabase Auth sono le tre che utilizziamo più frequentemente. Questi servizi gestiscono il lavoro pesante della conformità ai protocolli di autenticazione, MFA, SSO e gestione delle sessioni, e forniscono SDK che si integrano in modo pulito negli stack applicativi moderni. Non sono gratuiti su scala, ma il costo di un'autenticazione errata — in tempo di sviluppo, in incidenti di sicurezza, o in deal enterprise persi perché non si può supportare SAML SSO — è di gran lunga superiore.

La domanda architettuale chiave a cui rispondere prima di costruire: qual è il profilo del vostro acquirente enterprise? Se prevedete di vendere a qualsiasi organizzazione con un reparto IT, il supporto SSO non è facoltativo, e avete bisogno di un livello di autenticazione in grado di gestirlo.

---

Architettura della Fatturazione ad Abbonamento

La fatturazione è la seconda area in cui vediamo i fondatori sottovalutare drasticamente la complessità. Il percorso ideale — il cliente si registra, inserisce i dati della carta, paga mensilmente — è semplice. Tutto il resto non lo è.

Su scala, un sistema di fatturazione SaaS deve gestire:

• Prove gratuite (carta di credito richiesta vs non richiesta, conversione da trial a pagamento)
• Piani tariffari multipli con funzionalità e limiti diversi
• Upgrade e downgrade, inclusi gli addebiti proporzionali a metà ciclo
• Fatturazione a consumo — addebito basato sull'utilizzo (chiamate API, posti, archiviazione, transazioni)
• Fatturazione annuale vs mensile con sconti appropriati
• Fatturazione per i clienti che pagano tramite fattura anziché carta
• Gestione dei pagamenti falliti, flussi di sollecito e periodi di grazia
• Rimborsi e crediti
• Calcolo delle imposte (in particolare IVA/GST tra le giurisdizioni)
• Webhook dal vostro provider di pagamento per mantenere sincronizzato lo stato dell'applicazione

Costruire un sistema di fatturazione che gestisca tutto questo correttamente è un progetto di ingegneria significativo. Le modalità di errore sono costose — sia finanziariamente (addebiti applicati incorrettamente, upgrade falliti) sia in termini di fiducia dei clienti.

La nostra raccomandazione standard è Stripe Billing per l'infrastruttura di fatturazione principale. Stripe gestisce la complessità finanziaria — fatturazione, proration, solleciti, metodi di pagamento, imposte nelle regioni supportate — e la espone tramite un'API ben progettata. Il compito della vostra applicazione diventa gestire le autorizzazioni del piano (quali funzionalità un cliente su un determinato piano può accedere) e rispondere ai webhook di Stripe per mantenere il database sincronizzato con lo stato di fatturazione.

La tentazione di costruire la fatturazione internamente è quasi sempre un errore. Anche se il prezzo di Stripe sembra elevato rispetto ai ricavi iniziali, il tempo di sviluppo risparmiato — e le garanzie di correttezza che si ottengono — lo rendono il giusto compromesso per quasi ogni prodotto SaaS.

---

Architettura dei Dati per SaaS

Abbiamo accennato ai modelli di dati multi-tenant in precedenza, ma l'architettura dei dati va oltre il semplice luogo di archiviazione dei dati. Su scala, il modo in cui i dati sono strutturati determina la velocità con cui il prodotto può evolvere, la sicurezza con cui è possibile apportare modifiche e se è possibile adempiere agli obblighi nei confronti dei clienti.

Alcune cose da progettare deliberatamente fin dall'inizio:

Migrazioni di schema su scala. In un'applicazione con un singolo database, eseguire una migrazione del database è un'operazione singola. In un'architettura multi-schema o multi-database, eseguire la stessa migrazione significa applicarla correttamente a ogni ambiente tenant. Senza una solida strategia di migrazione (e gli strumenti per supportarla), questo diventa un collo di bottiglia nei deployment man mano che si cresce.

Soft delete vs hard delete. Nella maggior parte delle applicazioni SaaS, i dati non dovrebbero mai scomparire davvero quando un utente "elimina" qualcosa. I soft delete (contrassegnare un record come eliminato senza rimuoverlo) abilitano la funzionalità di annullamento, i log di audit e il ripristino dei dati — e sono molto più semplici da implementare fin dal primo giorno che da aggiungere successivamente.

Backup e disaster recovery. Qual è il vostro recovery time objective (RTO) se il database va offline? Qual è il vostro recovery point objective (RPO) — quanti dati potete permettervi di perdere? Queste sono decisioni di business che hanno implicazioni architetturali. I backup giornalieri automatizzati sono un minimo; il ripristino point-in-time è l'obiettivo giusto per qualsiasi prodotto in cui la perdita di dati avrebbe conseguenze gravi.

Esportazione ed eliminazione dei dati per il GDPR. Ogni prodotto SaaS che vende a clienti nel Regno Unito o nell'UE deve essere in grado di esportare i dati di un cliente specifico in un formato leggibile da macchina ed eliminarli definitivamente su richiesta. Se il vostro modello di dati non è stato progettato tenendo presente questo aspetto, soddisfare queste richieste manualmente su scala è un processo doloroso.

---

Progettazione delle API

Un prodotto SaaS API-first tratta la propria API come un prodotto di prima classe — non come un ripensamento per le integrazioni, ma come la fondazione su cui sono costruiti sia il frontend sia i consumatori terzi. Questo è importante perché:

• I vostri clienti vorranno costruire automazioni sopra il vostro prodotto
• Gli acquirenti enterprise chiederanno della vostra API nelle conversazioni di procurement
• Le applicazioni mobile, le estensioni del browser e le integrazioni con i partner dipendono tutte dalla qualità dell'API
• I vostri strumenti interni (dashboard, pannelli di amministrazione) costruiti sulla stessa API garantiscono la coerenza

I due paradigmi API dominanti sono REST e GraphQL. REST è più semplice, più ampiamente compreso e più facile da memorizzare nella cache — è il default corretto per la maggior parte dei prodotti SaaS. GraphQL ha vantaggi quando i requisiti di dati del frontend sono complessi e altamente variabili, ma aggiunge una complessità operativa di cui la maggior parte dei prodotti nelle prime fasi non ha bisogno.

Il versionamento delle API è una decisione architettuale facile da rimandare e dolorosa da aggiungere in seguito. Fin dall'inizio, la vostra API dovrebbe essere versionata (tipicamente /v1/ nel percorso URL o tramite header), in modo che quando si apportano modifiche breaking, sia possibile farlo senza costringere tutti i consumatori API esistenti ad aggiornarsi immediatamente. Interrompere l'integrazione di un cliente perché si è modificata la forma di una risposta API è un grave problema di fiducia.

---

Scalabilità e Infrastruttura

"Deve essere scalabile" è qualcosa che quasi ogni fondatore dice nella fase di discovery. Cosa significhi in realtà varia enormemente, e progettare per la scala sbagliata è un problema tanto quanto progettare senza considerare la scala.

La scalabilità verticale significa fornire ai server più risorse — più CPU, più memoria, più archiviazione. È semplice, non richiede modifiche al codice e funziona bene fino a un certo punto.

La scalabilità orizzontale significa eseguire più istanze dell'applicazione simultaneamente dietro un load balancer. Gestisce limiti di traffico molto più elevati ma richiede che l'applicazione sia stateless — ovvero che nessuna informazione su una sessione utente specifica venga memorizzata nella memoria del server applicativo. I dati di sessione devono risiedere in un archivio condiviso (Redis, un database) accessibile a tutte le istanze.

La verità onesta sulla scalabilità per la maggior parte dei prodotti SaaS: non è necessario progettare per la scalabilità orizzontale fin dal primo giorno. Un monolite ben strutturato in esecuzione su un'infrastruttura cloud di dimensioni appropriate può gestire decine di migliaia di utenti prima che la scalabilità diventi un collo di bottiglia. L'approccio corretto è costruire con la scalabilità in mente — sessioni stateless, query database che utilizzano correttamente gli indici, job in background gestiti in modo asincrono — senza over-engineering per una scala che potrebbe non essere raggiunta per anni.

Ciò in cui dovreste investire fin dal primo giorno è l'osservabilità: monitoraggio dell'applicazione (tassi di errore, tempi di risposta, segnalazione dei crash), monitoraggio dell'infrastruttura (CPU, memoria, numero di connessioni al database) e alerting che avvisi qualcuno prima che i clienti si accorgano del problema.

---

Le Decisioni Architetturali da Prendere Prima del Giorno 1

Prima che il vostro team di sviluppo scriva una riga di codice applicativo, queste decisioni dovrebbero essere prese e documentate:

• Modello multi-tenancy — pool, bridge o silo? (Determinato dal vostro mercato target e dai requisiti di conformità)
• Strategia di autenticazione — piattaforma di identità gestita (Auth0, Clerk) o personalizzata? SSO richiesto fin dal primo giorno?
• Infrastruttura di fatturazione — Stripe Billing come fonte di verità, con la vostra app che gestisce le autorizzazioni?
• Provider cloud target — AWS, GCP o Azure? Influisce sugli strumenti, sulle relazioni con i fornitori e sul pool di talenti
• Framework frontend — Next.js, Nuxt, SvelteKit? Importante per la composizione del team a lungo termine
• Database primario — PostgreSQL è il default corretto per la maggior parte dei prodotti SaaS; NoSQL ha casi d'uso specifici
• Standard di progettazione API — REST o GraphQL? Strategia di versionamento?
• Requisiti di residenza dei dati — qualche cliente richiede che i propri dati rimangano all'interno di una specifica area geografica?
• Architettura di deployment — monolite per iniziare, con confini chiari se i microservizi fossero necessari in seguito

---

Errori Architetturali Comuni nei Prodotti SaaS che Riscontriamo

Dopo aver costruito prodotti SaaS nel fintech, nella sanità, nella logistica e nei servizi professionali, abbiamo un quadro chiaro di cosa va storto — e quando.

Microservizi prematuri. Suddividere un prodotto in microservizi prima che i confini del dominio siano ben compresi crea un'enorme complessità operativa senza i relativi benefici. Iniziate con un monolite ben strutturato. Estraete i servizi quando avete una ragione chiara — un confine di ownership del team, un profilo di scalabilità radicalmente diverso, un confine di conformità. Non prima.

Nessun audit logging. I clienti enterprise si aspettano di sapere chi ha fatto cosa e quando nel vostro prodotto. I regolatori a volte lo richiedono. Aggiungere l'audit logging a posteriori in un modello di dati che non è stato progettato per esso è doloroso e spesso incompleto. Costruitelo fin dal primo giorno.

Assunzioni sui tenant codificate in modo rigido. Spesso vediamo prodotti in cui tenant_id è stato aggiunto ad alcune tabelle ma non ad altre, o in cui alcuni job in background elaborano i dati globalmente anziché per tenant. Queste incoerenze sono bug in attesa di manifestarsi, e diventano più difficili da correggere quanto più dati sono presenti nel sistema.

Mancata progettazione per l'esportazione dei dati (GDPR e abbandono). I clienti se ne vanno. Ai sensi della legge del Regno Unito/UE, potreste essere legalmente obbligati a fornire i loro dati in un formato portabile. Progettate il vostro modello di dati e le vostre API per rendere ciò possibile fin dall'inizio — non come progetto di emergenza quando il team legale del vostro primo cliente enterprise lo richiede.

Accoppiamento errato dello stato di fatturazione con lo stato applicativo. Utilizzare Stripe come fonte di verità della fatturazione ma mantenere anche lo stato del piano nel proprio database va bene — a patto che i due vengano mantenuti sincronizzati tramite la gestione dei webhook. Vediamo regolarmente prodotti in cui queste due fonti di verità divergono silenziosamente, con il risultato che i clienti hanno accesso a funzionalità per cui non stanno pagando, o (peggio) vengono bloccati dall'accesso a funzionalità per cui stanno pagando.

---

Come Progettiamo l'Architettura SaaS in Cyberbeak

Il nostro processo di discovery SaaS si svolge tipicamente nell'arco di due o tre settimane prima che inizi qualsiasi sviluppo. Durante questo periodo affrontiamo:

Mappatura del mercato e della conformità. Chi sono gli acquirenti target? In quali settori operano? Quali framework di conformità potrebbero emergere nelle conversazioni di procurement? Le risposte a queste domande determinano il modello multi-tenancy e i requisiti di autenticazione prima che venga presa qualsiasi altra decisione.

Progettazione del modello di dati. Progettiamo lo schema principale con multi-tenancy, soft delete, audit logging ed esportazione GDPR integrati fin dall'inizio. Questo viene fatto in modo collaborativo con il team fondatore in modo che tutti comprendano le relazioni tra i dati.

Mappatura delle integrazioni. A cosa deve connettersi il prodotto? A cosa deve connettersi il prodotto da parte di altri prodotti? Questo determina le priorità di progettazione delle API e i primi impegni di integrazione.

Progettazione dell'infrastruttura. Selezioniamo un provider cloud, definiamo la struttura dell'ambiente (sviluppo, staging, produzione), stabiliamo una pipeline CI/CD e configuriamo monitoraggio e alerting prima che venga costruita la prima funzionalità applicativa.

Il nostro stack predefinito per i nuovi prodotti SaaS in questa fase è Next.js (frontend), Node.js o Python sul backend a seconda della composizione del team e dei requisiti del prodotto, PostgreSQL come database principale, Stripe Billing per i pagamenti, Auth0 o Clerk per l'identità e AWS per l'infrastruttura. Non si tratta di un template rigido — ci adattiamo in base ai requisiti — ma riflette anni di esperienza nella costruzione e nel mantenimento di prodotti SaaS in produzione.

L'obiettivo della discovery non è produrre un piano perfetto. È portare alla luce le decisioni costose da invertire, prenderle esplicitamente e deliberatamente, e fornire al team di sviluppo una fondazione su cui costruire con fiducia.

---

FAQ

Quanto tempo richiede la pianificazione dell'architettura SaaS?

Per la maggior parte dei prodotti SaaS nelle prime fasi, una fase di discovery e architettura adeguata richiede da due a tre settimane. Per i prodotti più complessi — in particolare quelli con requisiti di conformità enterprise, modelli di dati complessi o molteplici dipendenze di integrazione — può richiedere da quattro a sei settimane. Questo investimento si ripaga molte volte prevenendo costose rielaborazioni negli sprint successivi.

È possibile iniziare con un'architettura più semplice e aggiornarla in seguito?

Alcune decisioni possono essere rinviate — non è necessario l'auto-scaling fin dal primo giorno, e molte integrazioni possono essere aggiunte man mano che il prodotto matura. Ma le decisioni fondamentali — modello multi-tenancy, strategia di autenticazione, infrastruttura di fatturazione — sono molto costose da modificare una volta che i dati dei clienti sono nel sistema. Raccomandiamo sempre di prendere queste decisioni deliberatamente all'inizio, anche se l'implementazione iniziale è semplice.

Abbiamo bisogno di microservizi per un prodotto SaaS?

Quasi certamente no al primo giorno, e probabilmente nemmeno per anni. I microservizi risolvono problemi reali, ma introducono una significativa complessità operativa. Un monolite ben strutturato è il punto di partenza corretto per la stragrande maggioranza dei prodotti SaaS. Progettiamo i monoliti con confini interni chiari in modo che l'estrazione dei servizi in seguito — se diventa genuinamente necessaria — sia un progetto gestibile piuttosto che una riscrittura.

Qual è il più grande errore architetturale che fanno i fondatori?

L'errore più comune e costoso è trattare l'architettura come un problema del team di sviluppo piuttosto che come una decisione condivisa. Quando i fondatori non fanno parte della conversazione sull'architettura, i default scelti sono spesso appropriati per l'interpretazione più semplice del prodotto — non per dove il prodotto deve effettivamente andare. Essere presenti, fare domande e prendere le decisioni chiave deliberatamente è una delle azioni a più alto impatto che un fondatore non tecnico può compiere prima che inizi un progetto.

---

Se siete in fase di scoping di un prodotto SaaS e volete assicurarvi che le decisioni architetturali siano corrette prima che inizi lo sviluppo, saremo lieti di parlarne. Il nostro processo di discovery è progettato specificamente per portare alla luce queste decisioni in anticipo, spiegarle chiaramente e fornirvi una fondazione che non dovrà essere ricostruita quando il vostro primo cliente enterprise porrà le domande giuste. Contattate il team Cyberbeak per iniziare la conversazione.