Build The SaaS, Or Fix The One You Already Run
Starting from nothing, or already carrying paying customers, the work is the same: keep every customer's data separated, let people see only what is theirs, and change it without downtime.
A technical read on your system
Describe what you run and a technical person usually replies within 24 hours. No sales sequence, no rebuild quote.
SaaS product development, for a product that already has paying tenants, is repair work rather than a rewrite. It means deciding tenancy, which is how each customer's data is kept apart, in one place instead of in every query, consolidating identity so one login serves the whole estate, and moving each seam as an increment where the old path stays live until the new one carries real traffic. The work runs in your own cloud accounts and repositories, and every line of it is your IP. If you are still building the first version of the product, that is MVP development; if the way customer data is separated already works and the problem is cost and speed under load, that is scale and optimize.
Your application started as one copy and one database per customer, and nothing has ever decided, in one place, which customer a request belongs to.
How we know
Five separate login platforms served one application estate before we consolidated authentication into one. The case study is published without the client's name, as all of ours are.
Industry data, not ours
What a major outage costs, across the industry
Show data table
| Segment | Value (%) | Share | Source |
|---|---|---|---|
| Under $100,000 | 43 | 43% | Balance of the same Uptime Institute analysis, after its two published cost bands |
| $100,000 to $1M | 37 | 37% | Uptime Institute annual outage analysis |
| More than $1M | 20 | 20% | Uptime Institute annual outage analysis |
More than half of major outages land above $100,000 in direct cost.
Rebuild, isolate, or repair
How much of the system can you afford to take offline while customer data is separated, and how many customers would notice if the move ran long?
Tenancy in application middleware
Choose this when
Every request already passes through one framework layer, and the team can hold the line that no query ever bypasses it.
It costs you
One missing filter is a cross-tenant read, and nothing in the database stops it. The isolation is a convention, so it holds exactly as long as code review does.
A database per customer
Choose this when
Tenants are few, large and contractually separate, and at least one of them is buying that isolation on paper.
It costs you
Every migration, deploy and incident is multiplied by the tenant count, and that count only goes up. Onboarding a customer becomes an operations task rather than a signup.
A parallel rewrite
Choose this when
The current system genuinely cannot carry another year of tenants, and the business can fund two products until the new one is real.
It costs you
You run two products. Every feature ships twice until cutover, and the cutover date moves each time a paying tenant needs something in the old one.
What gets separated, and where
Multi-tenant means many customers on one system, so every layer has to know whose data it is looking at. Six places that decision gets made.
| Layer | Where it lives todayThe shape we are usually called into | What changes | What we commit toWritten down before the work starts |
|---|---|---|---|
| Tenant identityWhich tenant a query belongs to | Where it lives todayDecided per query, in whatever code path happened to write it | What changesOne resolver every query passes through, at the edge of the data layer | What we commit toNo query reaches the database without a tenant already decided |
| Data isolation | Where it lives todayA database per client, or one shared table with a column nobody enforces | What changesA stated isolation model, enforced in the data layer instead of by habit | What we commit toA test that fails when one tenant can read another |
| Authentication | Where it lives todaySeveral login platforms, roughly one per application | What changesOne login system for the whole estate (an identity provider, using the OAuth 2.0 standard) | What we commit toOne login serves the estate, and the old ones retire on a named date |
| Background jobs | Where it lives todayJobs that infer the tenant from the queue they arrived on | What changesTenant carried on the job envelope, through the same resolver a request uses | What we commit toA job cannot run without a tenant on it |
| Migrations | Where it lives todayEvery schema change multiplied by the number of tenants | What changesOne migration path, applied per tenant on a schedule you can watch | What we commit toA migration that stalls is visible per tenant, not as a single number |
| Observability | Where it lives todayErrors from every tenant aggregated into one graph | What changesTenant on every log line, trace and metric | What we commit toA per-tenant error rate you can alert on |
How a repair runs
01
Read the system
A software engineer reads what you already run: how your customers’ data is kept apart today, where logins live, and the failure you can name.
You get
A written read of how customer data, logins and reliability are handled, in the order we would repair them.
02
Cut one seam
One seam moves first, usually the one the named failure runs through. The old path stays live while the new one is built beside it.
You get
The new path running in your own cloud accounts, behind a switch your team controls.
03
Move real traffic
Traffic shifts onto the new path a share at a time. The old path can take it back until the numbers hold for a full week.
You get
A written record of the switch over: what moved, when, and the numbers on both sides.
04
Hand it back
The repair is written into your own runbooks so your team owns it, and the next seam is either scheduled or honestly dropped.
You get
Runbooks, the migration scripts, and a written decision on which seam to repair next, or none.
What one consolidation moved
5 to 1login platforms
One Keycloak identity provider with OAuth 2.0 and user federation, across an application estate carrying thousands of monthly active users.
-70%auth-related support tickets
One login path instead of five, for the same application estate and the same set of users, after the consolidation.
-40%licence and development cost
Retiring four login platforms, and the code that had been keeping all five of them in step with each other.
Whether to call us
Where we fit
You run a live SaaS with paying tenants, and the tenancy model was never decided in one place.
Identity is spread across more than one login platform, and the support tickets follow it.
A migration or an incident costs you more with every tenant you add.
The product has to keep serving customers while the seams are repaired.
Where we are the wrong call
You have not built the product yet and need a first version in front of real users.
The way customer data is separated already works, and the problem is cost and speed under load.
The application is not multi-tenant at all and you want a team to extend it.
The system runs fine and what you want is a lower running cost and footprint.
Questions we get asked before the first call
Ownership, review, change control and life after launch, answered the same whether you are building the first version or repairing the one you run.
Who owns the code, and where does it run?
We have no technical team. Can we still do this?
What happens when the scope changes partway through?
How long does planning take before anything gets built?
Who reviews the code before it reaches paying customers?
What happens after launch?
Can you satisfy our auditors on security and compliance?
What if we want to take the work elsewhere later?
Get a technical read on your multi-tenant system
Tell us how customer data is kept apart today, how many customers you carry, and the one failure you can name. A software engineer reads it.
You have seen the routes, the layers we separate, how a repair runs and what one identity consolidation actually moved. The next step is that shape applied to the system you already operate rather than to a generic engagement.
Nothing here starts with a rebuild quote. The first reply names what we would repair first and what it would cost you to leave it alone.
- A software engineer replies, not a salesperson
- 50+ enterprise engagements across 7 countries since 2015
- Everything you share stays private
- No sales sequence and no rebuild quote