How to build multi-tenant SaaS - complete guide

If you are figuring out how to build multi-tenant SaaS, you are choosing how one app serves many customers without mixing their data, billing, or permissions. Get this wrong early and you rewrite the core of the product. Get it right and teams, invites, and plan gates become boring infrastructure.

What is multi-tenant SaaS?

Multi-tenant SaaS is software where a single deployed application serves multiple customers (tenants). Each tenant sees only its own data and settings, while you operate one codebase, one deploy pipeline, and usually one database.

Quotable definition: A tenant is the isolation boundary (usually an organization or workspace). Users are people; they can belong to many tenants through memberships with roles.

This is different from:

If you sell to companies, you almost always need multi-tenancy even if day one is "just me and a co-founder."

Choose the tenancy model (before you write features)

Decision rule: start shared. Design your app so the tenant key is always explicit. Later you can route a VIP customer to a dedicated database behind the same API without rewriting product code.

Industry guides from Shopify and Postgres-focused architecture writeups converge on the same default: shared schema first, silo only when required.

TurboStarter follows shared schema: one Postgres database, organizationId as the tenant separator, users joined via memberships.

Prerequisites

You need:

• A web app (typically Next.js App Router)
• PostgreSQL
• Session-based auth you control (or a self-hosted auth library such as Better Auth)
• An API layer that can run middleware (Hono, tRPC, or route handlers)
• Clear product language: Organization / Team / Workspace (pick one for UI; keep one internal name)

Optional but recommended:

• Email provider for invites
• Billing provider that supports a customer reference per org (Stripe, Lemon Squeezy, Polar, etc.)
• Wildcard DNS if you want acme.yourapp.com routing (subdomain recipe)

Build multi-tenant SaaS in seven steps

organizationId: text("organization_id")
  .notNull()
  .references(() => organization.id, { onDelete: "cascade" }),

const slug = (await params).organization;
const organization = await getOrganization({ slug });
if (!organization) notFound();

const membership = await getMembership({
  organizationId: organization.id,
  userId: session.user.id,
});
if (!membership) redirect("/unauthorized");

await auth.api.hasPermission({
  headers: await headers(),
  body: {
    permissions: {
      invitation: ["create"],
    },
  },
});

const projects = await db.query.project.findMany({
  where: eq(project.organizationId, organization.id),
});

Architecture cheat sheet

For a full production stack around this model, see best SaaS stack 2026. For whether to DIY the scaffolding, see boilerplate vs building from scratch.

Common mistakes

1. Trusting the client organizationId: always resolve tenant from session/slug, then authorize.
2. Filtering in the UI only: hidden buttons do not stop crafted API calls.
3. Forgetting background jobs: cron and queues need an explicit tenant id and the same guards.
4. Billing users while selling teams: you will rewrite checkout within months.
5. Schema-per-tenant too early: ops cost explodes before product-market fit.
6. Colliding global admin and org admin: platform operators and workspace admins are different roles.
7. Caches without tenant keys: stale CDN or React Query keys can leak across orgs.
8. Allowing reserved slugs (www, api, admin) when using subdomains.

When to use a starter instead of DIY

Build tenancy yourself when isolation is the product (compliance platform, multi-DB broker) or auditors require you to author every control.

Use a production starter when:

• You need paying B2B users in weeks, not months
• Orgs, invites, RBAC, and org billing are table stakes
• You want the same tenant model on web and later mobile/extension

TurboStarter ships organizations powered by Better Auth, path-based active org, invitations, RBAC, org-aware billing (including per-seat), admin tooling, and a documented path to subdomain tenancy. You still design your domain tables and product permissions; you skip rebuilding membership graphs and invite emails.

Frequently asked questions

Final verdict: how to build multi-tenant SaaS

Ship multi-tenant SaaS by treating the organization as the tenant, putting organizationId on every business row, resolving the active org from the URL or session, and enforcing membership + RBAC + billing on the server. Keep a shared database until a real customer pays for stronger isolation.

If you want that foundation already wired in a TypeScript monorepo (web, optional mobile and extension), start from TurboStarter organizations, skim the SaaS stack guide, and spend your first sprint on the workflow only your product can own.