SaaS Product Engineering

Multi-tenant is a data model decision, not a feature

Multi-tenant platforms where tenant isolation, permissions and billing are settled at the data model, before the first enterprise customer forces the question.

Why this comes up

Almost every SaaS platform we are asked to rescue was built for one customer first. That is a reasonable way to start — you cannot design for tenants you have not met. The trouble arrives at customer number twelve, when someone asks for their own subdomain, their own admin, their own retention policy, and an export of only their data. Each request is individually small. Together they describe a schema the system does not have.

The retrofit is the expensive part. Adding a tenant column to forty tables is a weekend. Proving that every query in the codebase actually filters on it is not, and neither is the audit conversation with the first customer who asks how you know their data cannot leak into someone else's report. The same goes for billing: metering usage is easy while the plan is flat, and becomes a data migration the moment pricing changes to per-seat with an annual commitment.

So we settle these at the start, on paper, while the answers are still cheap. Isolation strategy, the permission model, the billing primitives and the migration path off whatever exists today — decided before the first schema is written, because these four are the decisions that later resist being changed.

What you get

Deliverables, not adjectives

An isolation strategy you can defend

Shared schema with enforced row-level filtering, separate schemas, or separate databases — chosen against your compliance obligations and customer count, not by default. Enforcement sits at the query layer so isolation is not a rule every future developer has to remember, and the choice is written down with the reasoning, so the next team knows why.

A permission model that survives new roles

Roles, resources and actions modelled separately, so adding 'regional auditor, read-only, three branches' in year two is configuration rather than a release. We build the case that breaks naive models — the user who belongs to two tenants — before it becomes a support ticket.

Billing, metering and plan limits

Subscription lifecycle, proration, failed payments, dunning and the unglamorous states around them: trials that lapse, downgrades that strand data, accounts that must stay readable after cancellation. Usage recorded as immutable events, so a pricing change re-reads history instead of rewriting it.

Tenant operations and onboarding

Provisioning a new tenant as a repeatable operation rather than a manual checklist, plus per-tenant configuration, feature flags, seeded reference data, and the support tooling your team needs to answer 'what does this customer actually see?' without a database console.

Scope at a glance

Tenant isolation enforced at the schema and query layer
Subscription billing, usage metering and plan limits
Permission models that absorb new roles without a rewrite
Staged migration off legacy on-premise deployments

What we reach for

Defaults rather than rules. Each one gets argued against on a project where it does not fit — the reasoning matters more than the tool.

Data: PostgreSQL as the default, with row-level security where isolation must be enforced by the database rather than by convention.
Application: TypeScript across Node.js services and React front ends; Python where the work is data-shaped.
Billing: Stripe or Razorpay against an internal metering model, so the provider stays replaceable.
Identity: SSO and SAML where enterprise buyers require it, mapped onto the same internal permission model as everyone else.

How it runs

Durations are ranges because a single confident number this early is a guess in a suit.

Engagement shape

Fixed-scope first release, then an embedded team or retainer as the roadmap settles.

Typical duration

Twelve to twenty weeks to a first production tenant, depending on the domain.

Starts with

A scoping session that produces a written data model and a cut list — before any estimate is treated as a commitment.

When this is the wrong thing to buy

We would rather lose the enquiry here than three months in. If you recognise your situation below, say so on the first call and we will tell you what we would do instead.

A single-tenant internal tool with no plan to sell it. Multi-tenancy is a cost; do not pay it speculatively.
Adding a tenant column to a live system under deadline pressure. That is an audit and a migration plan first, and we would rather scope it as one.
Teams who want the architecture decided by us and then handed over without discussion. These choices bind your business model, so you have to hold them.

Questions we get asked

Can you make an existing single-tenant product multi-tenant?

Usually, but it starts as an audit rather than a build. We map every query path that touches customer data, identify where isolation would have to be enforced, and give you the cost of both routes — retrofit, or a parallel system with a migration. Sometimes the honest answer is that the retrofit is cheaper than it looks; sometimes one subsystem makes it far more expensive than a rewrite of that subsystem alone.

Which isolation model do you recommend?

It depends on how many tenants you expect and what you have promised them. Shared schema with enforced filtering scales to thousands of tenants cheaply and is the right default. Separate schemas suit dozens of large customers with divergent configuration. Separate databases are for contractual or regulatory isolation, and cost real money in operations. We pick against your actual constraints and write down why.

Do we own the code?

Yes, entirely. Repositories and cloud accounts are in your name from the first commit, not transferred at the end. Leaving us should be uneventful, and we would rather that be true from day one than promised in a contract clause.

How do you handle enterprise SSO requests?

We model identity separately from permissions from the start, so adding SAML or OIDC later is an authentication adapter rather than a rework of authorisation. It is the single most common late enterprise requirement, and it is cheap to design for and expensive to bolt on.

Talk to us about saas product engineering

Send the problem rather than a feature list. You will get an approach, a range and an honest view of what it takes — including whether you need this at all.

Book a 15-min strategy call