Multi-tenant platforms, built right the first time
Tenant isolation, billing and permissions are not features you add in version two. Retrofitting them is the single most expensive mistake we get called in to fix.
- Discipline
- Multi-tenant SaaS
architecture and build - Decided first
- Isolation, billing
and permissions - Proof
- We run our own
platforms on it - Location
- Cape Coral, FL
Working remotely
What we build in from day one
Not scheduled for version twoA claim almost no firm our size can make
We are our own customerWe do not only build SaaS for clients. We run our own, in production, with our own paying customers.
Two Adroited products are live today: an insurance claims and third-party administration platform, and a multi-tenant fitness platform serving gyms and athletes in eight languages.
That changes how we build for you. We have carried the pager for our own billing bugs, our own migrations and our own support load — so the trade-offs we recommend are ones we have already paid for.
The decisions that get expensive
Roughly in order of cost to reverseRetrofitting isolation, billing and permissions is the single most expensive mistake we get called in to fix.
A platform is not a bigger app. The architecture that carries one customer will carry a hundred only if somebody decided, before the first line, where a tenant begins and ends.
Related work: custom web applications, API integrations and UI and UX design.
The decisions that are expensive to reverse
ArchitectureMost of what makes a SaaS platform hard is settled in the first fortnight. These four are worth slowing down for, because changing any of them after you have customers is a migration rather than a change.
Tenant isolation
Shared schema, schema per tenant or database per tenant. Driven by customer size and compliance expectations, and enforced at the data layer so a missing filter fails closed.
The billing model
Per seat, per usage or flat. This shapes the data model, because you can only bill for what you have been counting from the beginning.
Plan gating
Which capabilities belong to which tier, expressed once in a way the whole application asks, rather than scattered through the code as conditionals.
The upgrade path
How a customer moves tiers mid-cycle, what proration applies, and what happens on downgrade to data the new plan no longer covers.
Questions we get asked
FAQ01 How is this different from building a web application?
Multi-tenancy, billing and self-service. A single-tenant application serves one organisation; a SaaS platform has to isolate many, meter what they use, charge them without human involvement, and let them sign up and cancel on their own. Those four things drive most of the architectural decisions and most of the cost.
02 Do you build the billing side too?
Yes. Subscription plans, trials, upgrades and downgrades with proration, dunning when a card fails, and per-plan feature gating are all part of the work. We build on Stripe, including connected accounts where the platform takes payments on behalf of its own customers.
03 How do you keep tenants’ data separate?
Isolation is enforced at the data-access layer rather than left to individual queries, so a missing filter fails closed instead of leaking. Which model — shared schema with a tenant key, schema per tenant, or database per tenant — depends on your customers’ size and compliance expectations, and it is a decision to make early because it is expensive to reverse.
04 Can you take over a half-built platform?
Often, yes. We start with an assessment: what works, what is load-bearing, and what will have to be replaced regardless. You get that honestly, including the case where continuing costs more than restarting. We run five of our own SaaS products, so we have made most of these mistakes on our own time.
Building a platform, not just an app?
The early architecture decisions are the expensive ones. Let’s get them right.