At twenty to five on a Tuesday, the office manager at a sixty-person accountancy practice ran a bulk update against the wrong filter and overwrote eleven weeks of client records. She rang the company that sells them their practice software and asked for one thing: put our account back the way it was on Monday.
The engineer on call was honest with her. Every customer lived in one shared database, and the only backup the team could restore would roll back all of them at once. Putting her firm back meant erasing a day of work for every other firm on the platform. So they didn’t. She spent three weeks re-keying records by hand, and at renewal the partners asked, in writing, what would stop it happening again.
Nobody asked about that Tuesday when the software was commissioned. The founder asked about the stack, the timeline, the price and the portfolio, which are the questions the vendor-selection guides we read for this piece tell you to ask. Those questions matter. They are also questions you could put to a company building a brochure site. The questions that decide whether a SaaS product survives its own customers are about multi-tenancy. In the guides to choosing a SaaS development company we read while researching this piece, the most any of them offered was a single line telling buyers to ask how a company handles tenant data isolation, with nothing on what a good answer sounds like.
This article does. Instead of a checklist, it follows one customer through its whole life inside a product like yours, from the minute it signs up to the day it leaves, and stops wherever a decision made on day one comes due. Call the accountancy practice Tenant 5. It’s an illustration, but every stop on its journey is a real design decision. By the end you’ll have twelve questions, in the order your own customers will make you answer them.
What Multi-Tenancy Means When You’re the One Paying for the Build
Multi-tenancy is the design that lets one running copy of your product serve many customers, with each customer seeing only its own data. For the person commissioning the build, it decides three costs that arrive later: keeping customers apart, treating one customer differently from the rest, and removing one customer cleanly when it leaves.
The vocabulary is worth thirty seconds, because every serious answer you get will use it. AWS’s SaaS Lens describes three models. In a silo, a tenant gets dedicated resources, anything from its own database to a completely separate stack. In a pool, tenants share infrastructure, which is where the economies of scale come from. A bridge mixes the two by service or layer, siloing some parts of the system and pooling others, for example because of the regulatory profile of a service’s data or how noisy its workload is.
Many B2B products start pooled, because a pool is cheaper to run and faster to change, and for most early products that’s a sensible decision. It’s also the decision that makes every question below harder. In a pool, the only thing standing between two customers’ data is software your development company writes, which is why the multi-tenant SaaS architecture deserves more of your attention than the framework does.
One idea is worth fixing before any sales call: signing in isn’t isolation. A user can be properly authenticated, hold the right role, and still reach another customer’s records if something further down forgets to ask which tenant the request belongs to. AWS describes crossing that boundary as “a significant and potentially unrecoverable event for a SaaS business”. That’s the stake. Now follow Tenant 5 in.
Day One: What Happens in the Minutes After a Customer Signs Up?
When a customer signs up, the product has to create a tenant, attach that tenant’s identifier to every record it will ever own, and refuse to run any request that doesn’t know which tenant it belongs to. Ask the development company to show you where the identifier is set, and what the code does when it’s missing.
For Tenant 5, the first ten minutes look ordinary. A workspace is created, the office manager becomes its first administrator, she invites four partners, and roles are assigned inside that workspace. Every row written from now on carries Tenant 5’s ID. None of that’s visible to her, and all of it’s being decided by the data model someone wrote before she arrived.
The answer you want to the missing-identifier question is that the request fails. It errors, it logs, it returns nothing. The answer that should worry you is that it “can’t happen”, because it can: a new endpoint written in a hurry, a script run by hand, a job queued without the context. Systems built to fail closed survive those mistakes. Systems built on the assumption that nobody will make them don’t.
Then ask a question that’s easy to miss at this stage: can one login belong to more than one tenant? Accountants serve several client firms. Agencies manage several brands. Consultants move between organisations. A data model that assumes one person equals one company is cheap on day one and very expensive to unpick once the first customer asks for it, which in B2B tends to be sooner than founders expect.
Week Two: Where Does the Tenant ID Go After the Web Server?
The tenant ID has to follow Tenant 5’s data everywhere it goes, not only through the web request. Background jobs, caches, search indexes, file storage, exports, logs and analytics all need it. A product that isolates tenants perfectly on screen and loosely everywhere else isn’t isolated, however good the demo looks.
The main screen is the part that gets tested most, because it’s the part everyone sees. The nightly job that builds reports, the cache that serves a dashboard, the search index that answers a query, the storage bucket that holds uploaded files: those are the places where a tenant ID is easiest to drop, because nobody clicks through them in a demo. Broken access control, the category most cross-tenant leaks fall under, sits at number one in the OWASP Top 10:2025.
Ask how the tenant ID moves through the API layer underneath the screens, and in particular whether any endpoint acts on a tenant ID taken from the request without checking that the signed-in user actually belongs to that tenant. An endpoint that trusts a tenant ID in the URL without that check lets any signed-in user try other tenants. Then ask the same question about every queue, cache key and index name. The pattern you want is boring and consistent: tenant context established once per request, checked against the signed-in user, and carried explicitly into everything downstream.
Finally, ask for the test. A development company that takes isolation seriously has an automated test that signs in as one tenant, asks for another tenant’s data through every route it can find, and fails the build if anything comes back. If the test exists, they will show it to you. If it doesn’t, you’ll hear about their code review process instead.
The Database Default That Quietly Skips Isolation
Row-level security in PostgreSQL lets the database itself refuse to return another tenant’s rows, even when the application asks for them. It’s the right backstop, and it carries a trap in the small print. The PostgreSQL documentation states that superusers and roles with the BYPASSRLS attribute always bypass row security, and that table owners normally bypass it as well, unless the table is set to FORCE ROW LEVEL SECURITY.
So the useful question isn’t whether they use row-level security. It’s which database role the application connects as, and whether that role can bypass the policies. If the application connects as the owner of its tables and nobody switched on FORCE, the policies can be written, reviewed and deployed, and still not apply to the one database role that carries every customer’s traffic. A good answer names the role, confirms it isn’t a superuser or a bypass role, and that it either isn’t the table owner or is subject to FORCE, shows that row-level security is enabled on every tenant table, checks that views don’t quietly run with the owner’s rights, and points to a test proving that a query made as Tenant 5 returns nothing that belongs to Tenant 6. Other databases have their own equivalents and their own defaults, and the question translates directly.
Month Six: What Happens When Another Customer Runs a Huge Report?
In a shared system, one heavy customer can slow everyone else down. This is the noisy neighbour problem. It can show up as failed requests, but it often arrives as a complaint that the product feels slow on Monday mornings. Ask what stops one tenant consuming the capacity every other tenant is paying for, and what that tenant sees when it hits the limit.
By month six there are forty customers. Tenant 31, a firm three times Tenant 5’s size, runs its year-end export at nine on a Monday, and every other customer’s dashboards crawl for twenty minutes. No data leaked and no contract was breached. Tenant 5 simply concludes that the product has got worse, and nothing in your monitoring tells you why unless someone built it to.
Microsoft’s architecture guidance defines the noisy neighbor problem as one tenant’s performance being degraded by another tenant’s activity, and lists what a provider can do about it, including monitoring resource use, applying resource governance such as throttling and rate limits, rebalancing tenants across instances, and restricting the operations tenants can perform. Some options on Microsoft’s fuller list, such as provisioning more infrastructure, are quick. Others, such as limits that customers can see and understand, need designing before customers are already complaining.
Ask what the per-tenant limits are, where they’re enforced, and whether heavy work such as exports and reports runs somewhere that can’t starve the interactive product. Then ask the commercial version of the same question: can they tell you what each tenant costs to run? A product that can’t attribute cost to a customer can’t price that customer properly, and Tenant 31 may be your least profitable account while looking like your biggest.
The Bad Tuesday: Can You Restore One Customer Without Restoring Everyone?
In a pooled database, not without preparation. Restoring one tenant can mean restoring the whole database somewhere separate and copying that tenant’s records back, which is slow and risky unless the tooling was built and rehearsed beforehand. Ask whether they have built it, how long a single-tenant restore takes, and when they last rehearsed one.
This is the question from the opening. None of the vendor-selection guides we read asked it, and the closest any came was a general question about backups. Microsoft’s multitenant data guidance puts it plainly: in a shared database, restoring a single tenant might require you to restore the database to a separate resource and selectively recover that tenant’s data.
Selectively recover sounds like a query. It’s closer to a small migration. Tenant 5’s rows have to come back without overwriting anything that other tenants changed since Monday, with foreign keys intact, uploaded files matched to the right records, search entries rebuilt and an audit trail recording exactly what was done. Doing that well while the customer is on the phone isn’t realistic. Doing it from a tested runbook, in a time you’ve measured on your own data and can quote to the customer, is.
There are honest alternatives, and a good development company will talk through them rather than promise the impossible. A siloed database per tenant makes restore, residency and deletion simpler, and makes running, migrating and monitoring the whole fleet more expensive. Soft deletes and record history reduce how often a restore is needed at all. Point-in-time recovery into a scratch instance, plus a rehearsed extraction script, covers many real accidents. The wrong answer is the one Tenant 5 got: a restore that works perfectly for everyone and is therefore useless for anyone.
If a Tuesday like that sounds uncomfortably close to a product you already run, tell us what it’s built on and we’ll tell you whether the fix is a restore tool, a redesign, or nothing at all.
Year Two: What Happens When a Customer Wants Its Own Database?
Sooner or later a larger customer asks for things a pooled product wasn’t built to offer: its own database, data held in a particular region, its own encryption keys, sign-in through its own identity provider. Ask how the architecture would move one tenant from shared to dedicated infrastructure without a rebuild, and what that move would cost.
In year two, Tenant 5 merges with a larger practice and becomes a two-hundred-person firm with an IT director and a procurement process. The product it chose when it had sixty staff is now being assessed by people who assess products for a living. This is where tiering earns its keep: most tenants stay in the pool, and the ones that need and pay for it get dedicated parts of the system.
Of these, single sign-on is the cheapest to prepare for. Enterprise single sign-on through SAML or OIDC, with each tenant bringing its own identity provider, is a routine piece of work when the authentication layer was designed for it and a painful one when it wasn’t. Data residency is harder: ask whether a tenant can be placed in a chosen region, and whether its backups and logs go with it, because residency that stops at the primary database is a sales claim rather than an architecture. Customer-managed encryption keys, held in the customer’s own key store so it can revoke the product’s access to its data, sit at the expensive end, cheap to plan for and costly to retrofit.
None of these belongs in version one of most products. All of them belong in the conversation before version one, because the single-tenant vs multi-tenant choice isn’t a single decision. It’s a dial, and you want to know in advance how far your architecture lets you turn it.
The Security Questionnaire That Comes With Enterprise Deals
Your customer’s procurement team will send you, in writing, the questions you should have asked your development company. Expect questions shaped like these:
- Where is our data stored, and can we choose the region?
- How is our data kept separate from other customers’ data, and has that separation been tested independently?
- Who at your company can access our data, and is every access logged?
- Can we export all of our data, in a usable format, whenever we ask?
- When we leave, how and when is our data deleted, including from backups?
If your development company can’t help you answer those five on the day you sign with them, you’ll be answering them alone on the day a contract depends on it.
The Last Day: What Happens to a Customer’s Data When It Leaves?
When a customer leaves, your contract under UK GDPR has to say you’ll delete or return its personal data, whichever it chooses, delete remaining copies unless UK law requires you to keep them, and make available the information needed to show you’ve met those obligations. Ask how offboarding works from end to end, backups included.
In year four, Tenant 5 is acquired by a national firm with its own system. The request is reasonable and specific: everything we hold, in a format the new system can read, followed by written confirmation that the rest has gone. The database is the easy part. Tenant 5’s data also lives in uploaded files, search indexes, analytics events, the email service, the support desk and every backup taken in the last retention period.
Backups are the awkward piece. Under the ICO’s controller and processor contract guidance, the contract must require the processor to delete or return all the personal data at the end of the contract and to delete existing copies unless UK law requires them to be kept. The same guidance accepts that data in backups may not be deletable immediately, and says that may be acceptable if appropriate safeguards are in place, such as putting the data beyond use straight away, the retention period is appropriate, and the data is deleted as soon as possible, for example on the next deletion cycle. That only works if somebody designed the backup retention with the promise in mind. The ICO notes that this guidance is under review following the Data (Use and Access) Act, and none of this is legal advice.
Ask them to walk you through offboarding one tenant: the export, the deletion, the backups, the third-party services, and the confirmation you send at the end. If the answer involves a developer running scripts against production by hand, you have your answer, and so will Tenant 5’s new owners.
The Twelve Questions, in the Order Your Customers Will Ask Them
Here are the twelve multi-tenancy questions to put to any SaaS development company before you sign, ordered by when a real customer will force the issue. None of them has a one-word answer. A company that has built multi-tenant products will answer each one with a mechanism, a test or a document you can read.
- Where is the tenant ID set on each request, and what happens when it’s missing?
- Can one login belong to more than one tenant?
- Does any endpoint act on a tenant ID supplied by the caller without checking that the signed-in user belongs to that tenant?
- What enforces tenant isolation inside the database, and can the application’s own database login bypass it?
- How does tenant context reach background jobs, caches, search indexes and file storage?
- What automated test proves one tenant can’t read another tenant’s data, and does it run on every release?
- What stops one tenant consuming capacity the others are paying for?
- Can you tell me what each tenant costs to run?
- Can you restore one tenant to a point in time without touching the rest, and when did you last rehearse it?
- How would you move one tenant to dedicated infrastructure, into another region, or onto its own encryption keys?
- Can each tenant bring its own single sign-on, and is every data access logged against the tenant?
- What happens, step by step, when a tenant leaves, including backups and third-party services?
Twelve is a lot for one meeting. If you only have time for three, ask about the database login, the isolation test and the single-tenant restore. Between them they cover whether isolation is real, whether anyone checks it, and whether the system can look after one customer on a bad day.
What a Good Answer Sounds Like
A good answer points at something you can check: a line of code, a test in the pipeline, a runbook with a date on it, a diagram somebody maintains. A weak answer points at a value. Five weak answers are worth recognising.
- “Our framework handles that.” Frameworks help. They don’t know which tenant a background job belongs to.
- “We’ve never had a leak.” The absence of an incident is not a test. Ask to see the test.
- “We can add multi-tenancy later.” You can, and it’s usually a rebuild of the data layer with live customers on it.
- “We’d just restore the database.” That restores every customer, which is the problem you asked about.
- “The cloud provider handles deletion.” The cloud provider doesn’t know which rows belong to Tenant 5.
One test costs nothing at all. Ask two different engineers on their team the same question, separately. If the answers differ, the design lives in somebody’s head rather than in the code, and heads leave.
When Multi-Tenancy Is the Wrong Question
Multi-tenancy is the wrong first question when you haven’t yet shown that anyone will pay. Before product-market fit, the risk most likely to end the company is building the wrong thing, not isolating the right thing badly. It’s also the wrong model when a handful of very large customers each need, and will fund, their own deployment.
SaaS doesn’t have to mean one shared database. Some products run a separate deployment per customer, and for a business selling to a few dozen large, regulated organisations that can be the more sensible design, with different economics and fewer of the questions above. What matters is that the choice is made on purpose, by someone who can explain the trade.
If you’re pre-revenue with a hypothesis rather than a customer list, the honest advice is often starting with an MVP instead of commissioning a full platform. The condition is that the MVP is built by people who know which of the twelve questions will come due first. A tenant ID in the schema from the first week costs almost nothing. Adding one after the first thousand sign-ups usually means reworking the data layer with customers on it.
We’d rather tell a founder that than sell a sixteen-week platform to a company that needs six weeks of proof. A multi-tenant product that nobody wants is still a product nobody wants.
How Empyreal Infotech Builds for the Twelve
Empyreal Infotech designs multi-tenancy in from the first commit rather than adding it at Series A. Tenant isolation is enforced by the database rather than left to application code, the workspace model is fixed on day one, and cost is attributed per tenant from the first week. We’ve shipped 84 SaaS builds since 2019, and the same six decisions open every one of them.
Those six are row-level security in the database, the workspace and organisation model, billing with seats and usage, role-based access with an audit log recording actor, tenant, IP address and timestamp on every action that touches data, single sign-on stubbed for SAML and OIDC so the first enterprise request is a one-day switch, and a kill-switch: one-click tenant suspend, plus one-click export of a whole workspace in CSV and JSON. The final phase of the build adds live SAML and OIDC, an exportable audit log, a signed data processing agreement and answers to security questionnaires.
On price, a fully custom SaaS build with us starts from £45K, and most multi-tenant builds we sign land between £65K and £120K, on a ten to sixteen week fixed-price scope. The audit week that produces the scope is fixed at £8K. Three of our 2025 clients passed acquirer reviews on the first walkthrough.
That covers the day-one questions directly. The database login, the isolation test, single-tenant restore, customer-managed keys and regional placement we answer in the scope document rather than on a web page, because the right answer depends on your database, your customers and your budget, and a product selling to thirty-person firms may not need all of them in its first year. Ask us for those answers in writing before you sign, the same as you would anyone else. What we won’t do is leave them unasked.
FAQ: Choosing a SaaS Development Company
What questions should I ask a SaaS development company?
Beyond cost, timeline and portfolio, ask how they isolate tenants: where the tenant ID is enforced, whether the database connection can bypass it, how one tenant’s load is contained, whether one tenant can be restored on its own, and what happens when a tenant leaves. Good answers point to code, tests and runbooks.
What is tenant isolation in SaaS?
Tenant isolation is the set of controls that stops one customer seeing or affecting another customer’s data and performance inside a shared product. It’s separate from login and permissions: a user can be correctly signed in and still reach another tenant’s data if isolation is missing further down the system.
What is the noisy neighbour problem in multi-tenant SaaS?
It’s when one customer’s heavy usage degrades performance for others sharing the same infrastructure. Typical controls are per-tenant rate limits and quotas, running heavy workloads separately from the interactive product, and monitoring usage by tenant so the problem is visible before customers report it.
Can you migrate from single-tenant to multi-tenant later?
Yes, though it usually means reworking the data layer with live customers, migrated a few tenants at a time. Some teams first give each existing customer its own deployment and consolidate later. Either route costs far more than designing for tenancy at the start, which is why the question belongs in the first scoping conversation.
Is SaaS always multi-tenant?
It depends where you draw the line. Some SaaS products give each customer dedicated infrastructure, and AWS still treats that as SaaS provided every customer shares one identity, onboarding and operational layer. Separate versions run with separate management look more like a managed service. Many B2B products end up mixing shared and dedicated parts.
Ask About Tenant 5 Before You Sign
Go back to the accountancy practice on that Tuesday afternoon. Nothing about the failure was exotic. The database worked, the backups worked, and the software did exactly what it had been built to do. It simply hadn’t been built for one customer to have a bad day on its own.
Every question in this piece is a version of that one. Not how the product serves a thousand customers, but what it does for one of them: when it signs up, when its data travels, when its neighbour gets loud, when it makes a mistake, when it outgrows the pool, and when it leaves. A development company with good answers for Tenant 5 has usually thought about the rest.
Take the twelve questions into your next vendor meeting and listen for mechanisms rather than reassurance. If you’d like to hear them answered about your own product first, send us a five-line brief. Mohit reads every first email and replies inside 24 hours on weekdays with a clear yes, a clear no, or the one question that decides it.
Build for the thousandth customer, but ask about the fifth.