Hai un’idea di software che potrebbe servire a decine, magari centinaia di aziende diverse. La domanda tecnica che decide tutto è: costruisci una copia separata per ogni cliente, oppure una sola piattaforma che li serve tutti tenendo i loro dati rigorosamente separati? La seconda strada è la web app multi-tenant, ed è il cuore di praticamente ogni prodotto SaaS moderno. Quando sviluppo una piattaforma destinata a più clienti, la multi-tenancy è una delle prime decisioni di architettura che prendo — e dalla quale dipendono costi, sicurezza e capacità di crescere.
Che cos’è una web app multi-tenant
“Tenant” significa inquilino. In un’architettura multi-tenant una singola istanza dell’applicazione — un solo codice, una sola infrastruttura — serve molte organizzazioni clienti, ciascuna delle quali vede soltanto i propri dati e i propri utenti. È il modello di Gmail, di Shopify, di qualsiasi gestionale in cloud: tutti usano lo stesso software, ma ognuno è isolato dagli altri.
L’alternativa è il modello single-tenant, dove ogni cliente ha una propria installazione dedicata. Funziona per pochi clienti con esigenze molto particolari, ma diventa insostenibile su scala: ogni aggiornamento va replicato decine di volte, e i costi di infrastruttura esplodono. Per un prodotto SaaS che punta a crescere, multi-tenant è quasi sempre la scelta giusta.
Il problema che risolve: scalare senza moltiplicare i costi
Immagina di lanciare un gestionale per officine meccaniche. Con il single-tenant, il decimo cliente significa la decima installazione da configurare, aggiornare e monitorare. Con il centesimo cliente, il lavoro di manutenzione ti seppellisce.
Con un’architettura multi-tenant, invece, aggiungere un cliente significa creare un nuovo record di organizzazione nel database. L’infrastruttura è condivisa, gli aggiornamenti si distribuiscono a tutti contemporaneamente, e il costo marginale di ogni nuovo cliente tende a zero. È esattamente ciò che rende sostenibile un modello in abbonamento: paghi l’infrastruttura una volta e la ammortizzi su tutti i tenant.
Come isolo i dati di ogni cliente
Il punto più delicato della multi-tenancy è l’isolamento: il cliente A non deve mai, in nessun caso, vedere i dati del cliente B. È una questione di fiducia e, quando ci sono dati personali, anche di conformità al GDPR. Ci sono tre approcci principali, e scelgo in base al progetto.
- Database condiviso, schema condiviso: tutti i tenant nelle stesse tabelle, distinti da una colonna
tenant_id. È il modello più efficiente ed economico, ideale per la maggior parte dei SaaS. Richiede però un’attenzione rigorosa: ogni singola query deve filtrare per tenant. - Database condiviso, schema separato: un’unica base dati ma schemi distinti per ogni cliente. Maggiore isolamento, complessità intermedia.
- Database separato per tenant: massimo isolamento, indicato per clienti enterprise con requisiti normativi stringenti. Più costoso da gestire.
Nella maggior parte dei casi parto dal modello a database condiviso con tenant_id, perché offre il miglior equilibrio tra costo e prestazioni. La chiave è blindare l’isolamento a livello applicativo: il filtro per tenant non viene mai lasciato alla buona volontà del singolo sviluppatore, ma applicato in modo centralizzato e automatico a ogni accesso ai dati.
Lo stack tecnico con cui costruisco una piattaforma SaaS
Quando realizzo una web app multi-tenant uso uno stack moderno e collaudato, lo stesso con cui ho costruito e gestisco i miei prodotti in produzione.
Frontend
Interfaccia in React con TypeScript: un’unica applicazione che si adatta al tenant connesso, mostrando il suo logo, i suoi dati e i suoi permessi. TypeScript dà solidità al codice e riduce i bug man mano che la piattaforma cresce.
Backend e database
Il backend gestisce autenticazione, autorizzazione e — soprattutto — l’isolamento per tenant a ogni richiesta. Come database uso tipicamente PostgreSQL, robusto e perfettamente adatto al modello multi-tenant, con indici sulla colonna tenant per mantenere veloci le query anche con molti clienti a bordo. L’autenticazione gestisce utenti, ruoli e permessi distinti per ogni organizzazione.
Infrastruttura
L’applicazione gira in container Docker orchestrati con Portainer, dietro un reverse proxy con certificato SSL e gestione centralizzata su HestiaCP. Questo permette di scalare le risorse quando i tenant aumentano, di rilasciare aggiornamenti senza fermare il servizio e di tenere sotto controllo backup e monitoraggio. È l’infrastruttura che amministro ogni giorno per i progetti che seguo.
Cosa significa per la tua azienda
Se stai pensando a un prodotto software da vendere ad altre aziende — un gestionale verticale, un portale, uno strumento di settore — la multi-tenancy è ciò che lo rende un vero SaaS scalabile invece di un progetto che si blocca dopo i primi clienti. Sbagliare questa architettura all’inizio significa doverla rifare da capo quando il prodotto inizia a funzionare: è uno degli errori più costosi nello sviluppo di un SaaS.
Io progetto la multi-tenancy fin dal primo giorno, pensando alla crescita futura ma senza sovra-ingegnerizzare le fasi iniziali. Sviluppo l’applicazione end-to-end — frontend, backend, database e infrastruttura — e la metto in produzione pronta ad accogliere il primo cliente e a scalare verso il centesimo. È lo stesso approccio con cui ho costruito e opero piattaforme reali come apicco.app e tandemops.app.
Costruiamo insieme la tua piattaforma SaaS
Se hai un’idea di software multi-cliente e vuoi un partner tecnico che la progetti per durare e crescere, posso aiutarti. Sviluppo web app e piattaforme SaaS su misura, con architettura multi-tenant solida, e le gestisco anche dopo il lancio.
Scopri i miei progetti su cornelcaba.com e contattami qui per parlare della tua idea: trasformiamo insieme un’intuizione in una piattaforma scalabile e pronta per il mercato.
