Every B2B SaaS founder we’ve worked with has hit the same fork in the road, often in the first sprint: ship single-tenant and figure out the rest later, or build multi-tenant from day one and slow down the demo? Almost every team picks single-tenant. Almost every team regrets it by customer ten.
The good news is that “multi-tenant from day one” isn’t the heroic rewrite people imagine. It’s mostly a handful of design decisions that cost about a week up front and a quarter of pain to retrofit. Here’s the playbook.
What “multi-tenant” actually means
Multi-tenancy is a property of three layers: data, identity and application. You don’t have to pick one model for all three.
- Data: shared schema with a
tenant_idcolumn on every row, separate schemas per tenant, or separate databases. We default to shared schema + tenant_id — cheapest to operate, fine for >99% of products. - Identity:users belong to one or more tenants, with role-based permissions scoped per tenant. Don’t conflate a user with a tenant; they’re two different objects.
- Application: a single deployment serves every tenant. Configuration, feature flags and branding are per-tenant; code is one.
The five pillars of a production SaaS
1. Tenant isolation
On the data layer, every query goes through a function that filters by tenant. PostgreSQL row-level security (RLS) is the cheapest way to make this physically impossible to skip — you can’t accidentally leak data even if a query forgets the where clause. Above the DB, every cache key, S3 prefix and queue topic should be namespaced with the tenant ID too.
2. Subscription & billing
Stripe (or Chargebee, or Paddle) handles plans, trials, proration, dunning and tax better than you ever will. The integration shape that scales: store Stripe customer + subscription IDs on the tenant, use webhooks to sync state, and never look at billing in your own database. Always idempotent — every webhook handler must be safe to receive twice.
3. Identity, auth & SSO
Email + password is fine for v0. By the time you have ten enterprise customers, you’ll need SAML SSO and SCIM provisioning — non-negotiable for IT teams. Build the abstraction right the first time (Auth.js, WorkOS, or Clerk) so adding SSO later is a configuration change, not a rewrite.
4. Observability & SLOs
Logs, metrics, traces — tagged with tenant_idfrom day one so you can answer “is the slowdown affecting one tenant or all of them?” in 30 seconds. Define SLOs you actually care about (e.g. p95 API latency < 200ms, error rate < 0.1%) and alert when the error budget burns — not on every spike.
5. Cost optimisation
Shared infrastructure means tenant 10 doesn’t need 10x the resources of tenant 1. The right-sized SaaS uses one set of containers, one database (or one cluster), one observability bill. Reserve capacity for steady-state, autoscale for spikes, kill anything not pulling its weight at the monthly review.
The shortcuts that cost the most later
A short list of decisions that look like wins on day one but compound into rewrites:
- Hardcoding subdomains.If you can’t add a new tenant without a DNS deploy, you don’t have a SaaS.
- Reusing the same admin user for all tenants.The moment you sell to a regulated buyer, you’ll need per-tenant audit logs of who changed what.
- Skipping the audit trail.Compliance + customer support both want this. It’s a cheap append-only table on day one and a six-month migration on day 365.
- Letting billing logic leak into product code.“If tenant is on the Pro plan show this button” sprinkled through the UI is the path to a permanent feature-flag system you never wanted.
How we approach this
Our default stack for a new SaaS build is multi-tenant from the first commit: PostgreSQL with RLS, Stripe for billing, Auth.js (or WorkOS for enterprise) for identity, OpenTelemetry to Datadog for observability, and a tenant-scoped feature-flag system so every “Pro-only” check is a one-liner. We document the pattern in our SaaS Product Development service page.
Takeaways
- Multi-tenant from day one costs a week; retrofitting costs a quarter.
- Shared schema +
tenant_id+ Postgres RLS is enough for ~99% of products. - Don’t reinvent billing, auth, SSO or observability. Use the boring tools.
- Tag everything (logs, metrics, queues, cache keys) with the tenant from the start.
- Audit trails are cheap to add early, painful to add late.
