Come costruirei un SaaS - tenant, fatturazione e ciò che lo rende un prodotto

Un MVP risponde: qualcuno finirà questo lavoro? Un SaaS risponde: molte aziende continueranno a pagare perché teniamo un solo codice per tutte? La seconda domanda non è «aggiungere Stripe e un login». È tenancy, fatturazione, onboarding e un modo per aiutare uno sconosciuto alle 2 di notte senza SSH nei loro dati.

Come sceglierei la stack di un MVP, l’ho già scritto. Qui lo strato successivo: quando la forma del business è software-as-a-service, cosa costruirei davvero, in che ordine, e cosa non copierei da Linear o Salesforce il primo mese.

1. Prima: è davvero un SaaS?

Molte «idee SaaS» sono un sistema su misura per un cliente con fattura mensile. Può essere un buon business. Non è SaaS. SaaS vuol dire: un prodotto, tanti tenant, iscrizione autonoma o vendita leggera, e il costo di aggiungere la prossima azienda vicino a zero - non un altro progetto.

• SaaS: tante organizzazioni, le stesse funzioni, fatturazione nel prodotto, l’uptime è vostro.
• Su misura: un acquirente, workflow unici, fatturate le richieste di modifica. Non fate finta che il secondo cliente «si collegherà e basta».
• Se i primi tre clienti hanno ciascuno bisogno di un fork, smettete di chiamarlo SaaS. Vendete progetti finché la sovrapposizione è ovvia - poi estraete il prodotto.

2. L’unità del prodotto è il workspace, non l’utente

Modellerei il dominio intorno a un’organizzazione (workspace, tenant, account - una parola, e ci restiamo). Gli utenti appartengono alle organizzazioni. I dati appartengono alle organizzazioni. Le fatture appartengono alle organizzazioni. Se partite da «User ha Projects», passerete sei mesi a bullonare team, inviti e «chi paga».

• L’organizzazione ha un piano, un’email di fatturazione e uno stato: trial, active, past_due, canceled.
• L’appartenenza è una riga: user + org + ruolo (owner, admin, member bastano all’inizio).
• Ogni tabella di business ha org_id. Una query senza org_id è un bug, non una scorciatoia.
• Inviti invece di «creare un utente per loro». Email, accettazione, arrivo nel workspace giusto.

3. Tenancy: database condiviso, isolamento stretto

Per un primo SaaS non aprirei un Postgres per cliente. Un database, org_id su ogni riga, e difesa in profondità perché un WHERE dimenticato non diventi una fuga. Database-per-tenant è per isolamento regolato o vicini rumorosi già misurati - non per il tenant numero quattro.

• Row-level security o un helper di query che inietta sempre org_id dalla sessione - non dal body del client.
• ID non indovinabili (UUID). I /org/12/invoices/4 sequenziali sono un invito.
• Storage file con prefisso org_id, URL firmati, mai un bucket pubblico di «tutti gli upload».
• Schema o database per tenant solo se un contratto, una checklist di conformità o un vero vicino rumoroso lo impone. Migrazioni su 200 schemi sono un prodotto che non volevate.

4. La fatturazione è una funzione, non un plugin per dopo

Se nessuno può pagare, non avete un SaaS. Metterei il Checkout sul percorso critico già dalla settimana due, anche se il resto dell’app è sottile. Una fase «fatturiamo a mano» va bene per i primi cinque design partner - poi la carta deve funzionare.

• Stripe Billing (o il processore che il vostro primo mercato usa davvero): products, prices, customer portal, webhooks. Non conservate i numeri di carta. Non scrivete un motore di sollecito.
• Uno o due piani, non sette. Un periodo di prova con una fine chiara. Dopo: sola lettura o blocco duro - sceglietene uno e ditelo nell’interfaccia.
• Prezzo su una cosa che il cliente capisce: posti, progetti o volume mensile. La fatturazione a consumo è potente e facile da sbagliare; partite da un posto o un piano fisso finché non sapete cos’è «l’uso».
• I webhook sono la fonte di verità per «è pagato?». Il vostro database specchia Stripe (o Paddle). Un cron che indovina è il modo in cui chiudete fuori un cliente pagante.

5. La stack che prenderei (e in cosa differisce da un MVP sito)

Il default web resta: Next.js, TypeScript, Tailwind, Postgres. Il SaaS aggiunge qualche pezzo di cui un sito marketing non ha bisogno - e non ha ancora bisogno di una rete di servizi.

• Auth che capisce le organizzazioni: Clerk, WorkOS, Auth.js più la tabella di appartenenza - non un flag globale «collegato».
• Lavori in background dal giorno uno se qualcosa è lento o ripetibile: email, webhook Stripe, export, chiamate LLM. Una coda semplice (Inngest, Trigger.dev o un worker sul VPS) batte un setTimeout in una funzione serverless.
• Email transazionale dal primo minuto: invito, ricevuta, «il vostro periodo di prova finisce venerdì». Se quella mail non arriva, il prodotto sembra morto.
• Feature flags per i piani (can_export, seat_limit), non if (org.plan === "pro") sparsi in cinquanta file.
• Hosting: Vercel più Postgres hosted va bene finché un worker o la residenza dei dati non dicono il contrario. Una regione basta. Il multi-region è un problema dopo.

6. L’onboarding è il prodotto della prima ora

I cruscotti SaaS vuoti non convertono. Disegnerei la prima sessione come un lavoro, non come un tour: creare il workspace, importare o digitare il primo record vero, invitare un collega, vedere un risultato. I tooltip su una tabella vuota non sono onboarding.

• Un workspace di esempio va bene se è chiaramente finto e a un clic da «inizia con i miei dati».
• Metrica di attivazione: hanno finito il lavoro centrale una volta, non «iscritti». Misurate quello. Vendete quello.
• Le impostazioni possono essere brutte. Lo stato vuoto dello schermo principale, no.

7. Operazioni: come supportare persone che non avete mai incontrato

Il giorno in cui un’organizzazione pagante scrive «non vedo le mie fatture», vi serve un percorso senza SSH di produzione. Aggiungerei un admin interno sottile prima del decimo cliente, non dopo il primo incidente.

• Admin: trovare l’organizzazione, vedere piano e ultimo webhook, impersonare in sola lettura, reinviare l’invito. Tracciate l’impersonazione.
• Log con org_id e request id. «È fallito» senza tenant non è una riga di log, è una alzata di spalle.
• Backup che avete ripristinato una volta. Di notte basta all’inizio; un backup non testato è una storia che vi raccontate.
• Una pagina di stato può aspettare. Una email «siamo giù, ecco cosa sappiamo», no.

8. Cosa non costruirei il primo anno

Un grande SaaS è un museo di funzioni che si sono pagate dopo. Copiare il museo è mancare l’unico lavoro.

• SSO, SCIM e un questionario di sicurezza di 40 pagine solo quando un accordo vero è bloccato lì. Allora sono lo sprint, non una quest secondaria.
• Un’API pubblica e un marketplace di integrazioni. Un Zapier o un export CSV spesso sblocca lo stesso acquirente.
• Domini propri per tenant, white-label e uno studio temi. Un upload del logo basta per la maggior parte del B2B precoce.
• IA dappertutto. Un posto dove il linguaggio è il lavoro (ricerca, bozze, estrazione), con uno schema e un contatore fatturabile. Non una bolla di chat su ogni schermo.

9. Una sequenza che seguirei davvero

La stessa onestà di calendario di un MVP, con milestone a forma SaaS. Se una settimana non ha tenant, pagamento o lavoro, non è una settimana SaaS.

• Settimana 0: nominare il lavoro, l’acquirente, il piano, il numero di stop (es. cinque organizzazioni paganti in 90 giorni o si ferma). I non-obiettivi su una pagina.
• Settimane 1-2: organizzazione + appartenenza + un happy path in produzione + Stripe test mode. Test di isolamento: user A non deve vedere user B.
• Settimane 3-4: fatturazione live, inviti, email, onboarding di stato vuoto, admin sottile. Mostratelo ad aziende nominate, non «a internet».
• Giorni 30-90: guardare attivazione e ragioni di abbandono. Aggiungere l’unica integrazione o report per cui pagano. Non aggiungere un secondo prodotto.

Conclusione: affittate un lavoro, non una piattaforma

Costruirei un SaaS tanto poco glamour quanto un MVP, più le parti che fanno condividere un sistema a molte aziende: un workspace, una fattura, un muro tra tenant, una prima ora che non è vuota, e un admin perché il supporto non sia una root shell. La stack può restare noiosa. Il prodotto, no.

Se avete un workflow che più aziende vi pagano già per ripetere, e lo volete come prodotto invece che come pila di deploy su misura - scrivete dalla sezione contatti. Possiamo nominare il modello di tenant, il primo piano e una fetta che prende una carta senza fingere di essere Salesforce.