Tenant model
Organisations, members, roles and invitations, with every customer owned table carrying a tenant key and every query scoped to it.
Solution
Multi Tenant and White Label SaaS
Software one codebase serves to many customers, each with isolated data, its own branding and domain, and billing that matches what it uses.
Overview
What the system does
Multi tenancy means one deployment serving many customer organisations. It is cheaper to run and faster to improve than one instance per customer, and it is unforgiving about isolation.
White label adds a second layer: each tenant presents the product as its own, with its own domain, brand and sometimes its own pricing to its own customers.
The decisions that matter are made in the first week: how tenancy is enforced, how tenants are resolved from a request, and how billing relates to usage.
Who needs this
Product businesses serving several customer organizations from one software platform with tenant-specific branding and configuration.
What we build
Resolve a tenant from an approved hostname or membership, then enforce its boundary at each query and job. White-label branding is configuration, not a reason to fork the application. A subdomain is a routing signal, not authorization.
Modules
Core modules
Isolation enforcement
Tenant scoping at the application and data layers, with row-level security where appropriate. Cross-tenant tests cover queries, background jobs, exports and storage access; no individual control is treated as a universal guarantee.
Tenant resolution
Subdomain, custom domain or path based routing, resolved before the request reaches application logic, with certificate provisioning for custom domains.
Branding and theming
Per tenant logo, colour, typography and email templates driven by tokens, so a tenant looks like itself without a separate build.
Configuration
Feature flags, limits and settings per tenant, with defaults and overrides rather than forked code.
Billing
Plans, seats and usage metering per tenant, with entitlement derived from subscription state, and revenue sharing where tenants resell.
Administration
Platform level tooling to create tenants, inspect usage, impersonate with an audit record, and suspend.
Noisy neighbour controls
Per tenant rate limits and queue fairness, so one heavy tenant does not degrade the rest.
Data export and offboarding
A complete export per tenant and a defined deletion process, which matters for contracts and for privacy law.
Architecture
How it fits together
A typical implementation flow, with explicit responsibilities at each boundary.
Integrations
- Payment processors including connected accounts for revenue sharing
- Certificate issuance for custom domains
- Identity providers for tenant single sign on
- Transactional email with per tenant sending identity
- Object storage partitioned per tenant
- Analytics with tenant scoped reporting
- 01
Resolve
Match the request to a verified tenant and authenticated membership.
- 02
Enforce
Scope data, jobs, storage and configuration to that tenant.
- 03
Operate
Meter usage, apply fair resource limits and export or offboard one tenant safely.
Security and controls
Design for the exceptions, not just the happy path.
Test cross-tenant access in APIs, background jobs and signed URLs. Restrict platform administration and record support access. Row-level security is defense in depth, not a guarantee against every application defect.
Technology options
We select the final stack after reviewing your existing systems and operating requirements.
Security and IP practicesFit
Industries that use this
FAQ
Questions people actually ask
One database or one per tenant?
A shared database with a tenant key and row level security suits most products and is far cheaper to operate. A separate database per tenant is worth it when a contract or a regulator requires physical separation, and we say which applies rather than defaulting.
How do you prove isolation works?
With tests that deliberately try to cross the boundary, using identifiers from another tenant, and with row level security as a second layer so an application mistake still fails closed.
Can tenants use their own domain?
Yes, with automated certificate issuance and verification. The tenant points a record at the platform and the rest is handled.
Can tenants resell to their own customers?
Yes. Revenue sharing through connected accounts lets a tenant charge its customers with the platform taking its share automatically.
What stops one tenant slowing everyone down?
Per tenant rate limits, queue fairness for background work, and query budgets. Without them, one large import degrades the whole platform.
Can tenancy be added later?
It can, but it is close to a rewrite of the data layer and every query. It is the one thing worth building correctly on day one.
Let’s talk about the system you need.
Tell us where the current process breaks down. We can map the workflow, examine the integration requirements and define a practical scope for the build.
- A mutual NDA is signed before project details are shared.
- Scope is fixed in writing before any build starts.
- You own the source code, the IP and the documentation at delivery.
- Support plans are available and tailored on a discovery or technical call.