SaaS architecture for your first 1,000 customers (and beyond)
The decisions you make in the first sprint determine whether your SaaS scales gracefully or rewrites in year two. A practical guide to multi-tenancy, billing, and the auth layer that enterprise will demand.
The first three architectural decisions
Every SaaS makes three choices in its first sprint that it lives with for years: tenancy model, billing primitives, and the auth/identity layer. Get these right early and the rest of the system bends to your roadmap. Get them wrong and you'll be re-platforming when enterprise calls.
Tenancy: shared schema or isolated?
Shared-schema tenancy (a tenantId column on every table) is the right default for almost every B2B SaaS up to ~10,000 paying customers. It's simpler, cheaper, and faster to operate. Migrations apply to all tenants at once. Backups are one job, not N.
Switch to isolated schemas (or isolated databases) only when an enterprise prospect demands it or when a tenant's data volume meaningfully outweighs the average — usually in year three or four.
Billing: build for change, not perfection
Stripe is the answer. The interesting decision is how you map Stripe to your domain. Don't model plans as enums in code — model them as data, with versions, so you can grandfather pricing without redeploying.
Auth: SSO is not optional
Build OIDC + SAML in from the start, even if your first customer doesn't need it. The day you sell to a 500-person company is not the day to bolt on enterprise auth.
These three calls — tenancy, billing, auth — set the ceiling on how big you can grow without a rewrite. Spend the extra week.