Multi-tenant on day one

Almost every SaaS rewrite we've been called in to rescue traces back to the same three words the original team said in month one: "we'll add that later." Multi-tenancy, role-based access, real billing. They feel like things you bolt on once you have customers. They are the opposite — they are the shape of the building, and you cannot change the foundations after the walls are up without knocking it down.

We've built platforms that now run in more than 40 countries on a single codebase. The reason that was possible is boring and unanimous: tenancy, access and billing were decided on day one, before the first feature. This is what those decisions look like, and what it costs when you defer them.

01Why teams skip it (and why it's a trap)

The pressure is real. You have one pilot customer, a demo next week, and a backlog of features that actually look like the product. Multi-tenancy is invisible to that first customer — they can't see it, so it feels like gold-plating. So the team builds a single-tenant app "for now" and promises to generalise it later.

The trap is that "single-tenant for now" leaks one assumption into every layer: that there is exactly one organisation in the world. That assumption ends up in your queries, your auth, your caches, your background jobs, your file paths. Pulling it back out later isn't a refactor — it's a rewrite, because the assumption isn't in one place, it's in every place.

02The tenant is the first column

Our rule is simple: every row that belongs to a customer carries a tenant_id, and there is no code path that can query without one. Not a convention people remember — a constraint the database and the framework enforce, so forgetting it is impossible rather than merely discouraged.

The cleanest version we use leans on the database itself. Row-level security policies mean the tenant boundary is enforced one layer below your application code, where an ORM bug or a forgotten WHERE clause can't leak one customer's data to another. The application sets the current tenant on the connection; the database refuses to return anything else.

-- the boundary lives below the app, not inside it
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.tenant')::uuid);

-- app sets the tenant per request; a forgotten WHERE
-- clause now returns zero rows instead of someone else's data
SET app.tenant = 'a91f…';
SELECT * FROM orders;   -- only this tenant's orders, always

This single decision removes an entire class of catastrophic bugs — the cross-tenant data leak — from your worry list permanently. It is the highest-leverage two days of work in the whole project.

03RBAC is not a settings page

The second "later" that becomes a rewrite is access control. Teams ship with an implicit two-role world — admin and user — hard-coded into if statements scattered across the codebase. Then an enterprise customer asks for a "billing-only" role, or a "read-only auditor," and you discover permission logic in two hundred places.

We model permissions as data from the start: roles, permissions, and the grants between them live in tables, and every protected action asks one central authority "can this actor do this thing to this resource, in this tenant?" Adding a role becomes a row, not a release. That's what lets a platform say yes to the enterprise customer's org chart without touching application code.

• Permissions are verbs on resources — invoice:read, invoice:void — not vague levels like "manager."
• Roles are bundles of permissions a tenant can compose, so two customers can mean different things by "admin."
• Every check goes through one gate. Authorisation logic in one place is auditable; scattered if statements are a liability.

04Billing is product, not plumbing

Billing is where "we'll add it later" hurts most, because by the time you add it you have customers on handshake deals, inconsistent data about who owes what, and no clean concept of a subscription. Retrofitting billing means reconciling money, which is the one place a bug isn't just embarrassing — it's a refund, a dispute, or a compliance problem.

We design the billing model alongside the tenant model: plans, subscriptions, usage, invoices, and the lifecycle between them. Even if the first customers are invoiced manually, the data model is there from day one, so turning on self-serve plans later is a feature, not a migration of your entire revenue history.

05Forty countries, one codebase

Reaching 40+ countries sounds like a scaling story. It's really a configuration story. The platform doesn't have country-specific code branches — it has a tenant model rich enough to express what differs per region as data: currency, tax rules, language, date formats, the legal text on an invoice.

When the boundary between "code" and "configuration" is drawn correctly on day one, a new country is an onboarding task, not an engineering project. When it's drawn wrong, every new market is a fork, and within a year you're maintaining a dozen subtly different versions of the same app and shipping every fix a dozen times. The single-codebase outcome is downstream of decisions made before the first customer.

06The day-one checklist

If you're starting a SaaS platform this quarter, these are the decisions to make before you write a feature — not because they're urgent, but because they're irreversible:

1. Put tenant_id on everything and enforce it below the app. Row-level security or equivalent. Make a cross-tenant query impossible, not unlikely.
2. Model permissions as data. Roles and grants in tables, one central authorisation gate. Adding a role should be a row.
3. Build the billing data model early. Plans, subscriptions, invoices — even if you invoice by hand at first. Don't retrofit money.
4. Separate code from configuration. Anything that varies by customer or region is data. Country number 41 should be an onboarding form.
5. Write the tenant-provisioning path first. Creating a new tenant cleanly, with sane defaults, is your most-run operation. Automate it on day one.

None of this is exotic. It's a few weeks of discipline at the start in exchange for never doing the rewrite. The teams that reach 40 countries on one codebase didn't get lucky — they just refused to say "later" about the three things that can't be added later.