Multi-tenant SaaS in production

Club platform

One codebase serving several fully branded tenants with isolated data and role-based access, running in production.

Sheet
W-01
Title
Case study
Issued for
Information
Drawn by
Snilld

Sheet W-01 · Multi-tenant SaaS in production · Sport and recreation

Live
Goes in
One codebase, one deployment, one owner console
What we built
The host decides which tenant you are, and every query is scoped to it
Comes out
Four branded sites, each with its own content, roles and members
The line it does not cross
No tenant can read another tenant’s data

Note 1 · The constraint

An operator running more than one site, brand or franchise usually ends up with a separate installation per customer. Every change then has to be made several times, and the copies drift apart within a year.

Note 2 · What we built

A single application serves an owner console and any number of branded tenant sites. Each tenant gets its own host, its own branding and its own content, while data stays scoped so one tenant can never read another. Roles run from platform owner down to member, and the whole thing is covered by roughly 1,290 automated tests that run on every push.

Note 3 · What transfers

This is the engineering that lets one system serve many customers, branches or franchisees without forking it per customer. A vendor portal, a dealer network or a multi-site operations tool is the same problem wearing different clothes.

A platform we operate

This one is a product we own, host and run. It has its own site, with pricing and a way in.

Tenants live
Four
Automated tests
~1,290
Hosting
Oracle Cloud, Hyderabad
Tenant isolation
Per-tenant data scoping

Start with a prototype

Two to four weeks working from your own files, and at the end you hold something real. It is the cheapest way to find out whether any of this applies to you.

Start with a prototype