Building Multi-Tenant SaaS: What Actually Matters Early
Most SaaS products don't fail because the code was bad. They fail because a decision made in week two — how tenants share data — quietly becomes unchangeable by month six. Here's where to spend your attention early.
Pick an isolation model on purpose
There are three common shapes, and the right one depends on your compliance needs and scale — not on what feels cleanest.
- Shared schema, row-level isolation. Every table carries a
tenantId. Cheapest to run, easiest to ship, and the default for most B2B products. - Schema per tenant. Stronger separation, more operational overhead. Reasonable when tenants demand it contractually.
- Database per tenant. Maximum isolation, real cost. Justify it with regulation, not nerves.
For the large majority of products, shared schema with a disciplined tenantId is the correct answer — provided you enforce it in one place.
Make the data layer tenant-aware, not the callers
The single most common multi-tenant bug is a query that forgets its tenantId and leaks one customer's data to another. You cannot fix this with code review — reviewers miss it. Fix it structurally: every read and write goes through a scoped repository that injects the tenant filter automatically, so an unscoped query is impossible to write, not merely discouraged.
If a junior developer can write a query that returns another tenant's rows, your architecture — not your team — is the problem.
Choose a billing model before you have customers
Seat-based, usage-based, and flat-tier pricing each imply a different data model. Usage billing needs an events pipeline from day one; seat billing needs a clean concept of "active member." Retrofitting metering onto a product that never recorded events is a multi-week detour. Decide now, even if the numbers change later.
What you can safely defer
Not everything deserves early attention. SSO, granular role permissions, and audit logs are real features — but they're additive. They bolt onto a clean tenant model without forcing a rewrite. Don't let them crowd out the three decisions above.
Get isolation, the data layer, and billing right, and almost everything else stays a normal feature. Get them wrong, and they become a migration.