Delivery and product
Turn one customer’s product into a platform
Products built for a first customer often carry that customer in the code. We design tenant isolation, onboarding and metering, and move the product to a multi-tenant platform in stages.
- Duration
- 3 to 9 months
- Model
- Staged programme
- Output
- Multi-tenant platform in production
Signs the product is not yet a platform
Each new customer should be a configuration, not a project. When these are true, it is still a project.
- Every new customer needs its own deployment, and onboarding takes weeks of engineering time.
- Customer-specific branches and feature flags have multiplied until nobody knows which customer runs which code.
- One large customer’s workload slows down everyone else.
- Customer data is separated by convention in the code, and nobody could prove to an auditor that it cannot leak.
- Pricing by usage or by seat is on the roadmap, but the system cannot count what customers actually use.
- Upgrades are rolled out customer by customer, so versions drift apart.
- Enterprise prospects ask about data residency or dedicated environments, and the answer is a custom project every time.
Isolation is a business decision
Multi-tenancy is not one pattern. A shared database with a tenant column, a schema per tenant and a dedicated stack per customer are all valid, and each has a different cost, risk and sales story. Choosing without looking at your customer mix is how platforms end up being rebuilt twice.
We decide the isolation model with your commercial reality in view: how many tenants, how different their sizes, which of them need dedicated resources or data residency, and what an auditor will ask. Usually the answer is a tiered model, with shared infrastructure for most tenants and isolated options for the few that need them.
The move happens in stages. Tenant context is introduced into the code, data is separated, onboarding is automated and metering is added, while existing customers keep working. The milestone that matters is the first new tenant onboarded without an engineering project.
Scope
Included
- Tenant isolation model and tiering
- Tenant context in code, data and infrastructure
- Automated tenant onboarding and offboarding
- Usage metering and the hooks billing needs
- Per-tenant configuration instead of customer branches
- Noisy-neighbour protection and per-tenant limits
- Data residency and dedicated environment options
- Migration of existing customers onto the platform
Not included
- Choosing or implementing a billing product
- Sales pricing strategy
- Front-end redesign of the product
- Customer support processes
How the programme runs
- Weeks 1 to 4Decide the model. Customer mix, data sensitivity and growth plans are mapped. The isolation model and its tiers are chosen and written down with their trade-offs.
- Months 2 to 4Build the foundations. Tenant context, data separation, automated onboarding and metering are built into the product behind switches, without disturbing current customers.
- Month 4 onwardMove customers across. Existing customers are moved onto the platform one group at a time, and every move is verified and reversible.
- ThroughoutMeasure. Onboarding time, per-tenant resource use and upgrade effort are measured from the start, so the result is visible in numbers.
What you receive
The platform is built in your code and your cloud accounts, and your team owns it.
Who this service is not for
- Products with one or two customers and no plan for more. Multi-tenancy adds complexity that only pays off at scale.
- Teams expecting a ready-made SaaS template. Isolation, metering and onboarding are designed around your product and your customers.
- Programmes where all existing customers must move on the same day. We move them in groups to keep the risk small.
Frequently asked questions
Shared database or a database per tenant?
It depends on the number of tenants, the sensitivity of their data and how different they are in size. Most products end up with a tiered model: shared for most tenants, isolated for the few who need it. We decide with your customer list in front of us.
Can we keep serving current customers during the change?
Yes. The platform foundations are built behind switches and customers are moved in groups, each move reversible.
Do you build the billing system?
We build the metering and the hooks a billing system needs. Choosing and running the billing product itself is usually better done with a dedicated provider.
How do you handle a customer who needs its own environment?
As a tier of the same platform: the same code and the same onboarding process, deployed to dedicated resources. It stays one product, not a fork.
When is the first customer onboarded without engineering work?
That is the main milestone of the programme. Its date is set in the first weeks, once the isolation model is decided.
Start with a short technical call
Thirty minutes. You describe the product and your customers, and we tell you which isolation model fits and where the work starts.