Multi-tenant and white-label SaaS · Build
Multi-tenant SaaS that keeps each customer’s data apart
For SaaS sold to many businesses or under many brands, the database or data layer keeps customers apart. A design system we built serves more than 30 brands.
EngagementHourly · remote
Hours9–18 CET · 4 h overlap
StackPostgreSQL (row-level security) · Prisma · NestJS
Proof3 case studies
The service in 4 parts
01 · Who it’s for
SaaS companies that sell one product to many businesses, or sell it under many brands, from a single codebase.
02 · What we’ve built
- A white-label meeting platform for healthcare and finance. Whether someone may open a file depends on a chain of relationships: the meetings they attended, the documents linked to those meetings, and the versions and signatures of each document.Case study 15 →
- A design system of about a hundred components serving more than thirty white-label brands, each brand a set of token values. Three years later the same client came back to have their Android app rescued.Case study 02 →
- On a truck-services marketplace, one codebase served five kinds of user: service vendors, fleet carriers, owner operators, company drivers and call center staff. A permission combines type and role, so a vendor’s operator and a fleet carrier’s operator have different rights.Case study 08 →
Two multi-tenant products of our own are in development. In one, the database enforces isolation, and the build fails if a table is added without an access policy. In the other, a query that runs without a tenant context returns nothing.
03 · How we work
01 · TENANT BOUNDARYWe settle it once, where requests enter the system: where the tenant comes from, what happens when it is missing, and which queries may run without it. Usually the answer to the last question is none.
02 · BRANDS AS DATAThe components read every color from tokens, so a brand lives entirely in its token values. Building brands into the components instead would turn a hundred components and thirty brands into three thousand variants to maintain.
04 · Stack
PostgreSQL (row-level security)PrismaNestJSNext.jsdesign tokens per brand
Proof
Where we’ve done this before
Case study 15 · Business systemsSoldA white-label meeting platform for healthcare and finance. Whether someone may open a file depends on a chain of relationships: the meetings they attended, the documents linked to those meetings, and the versions and signatures of each document.Read the case study →Case study 02 · Platforms~100 / 30+A design system of about a hundred components serving more than thirty white-label brands, each brand a set of token values. Three years later the same client came back to have their Android app rescued.Read the case study →Case study 08 · Marketplace506 routesOn a truck-services marketplace, one codebase served five kinds of user: service vendors, fleet carriers, owner operators, company drivers and call center staff. A permission combines type and role, so a vendor’s operator and a fleet carrier’s operator have different rights.Read the case study →
FAQ
Questions about this service
It depends on who writes the queries. When many people and tools write them, row-level security in the database is worth its cost, because none of them can forget it. With one small team and a single access path, enforcing it in code can be enough. We explain the reason for whichever we choose.
From both, for different jobs. The domain decides whose content is shown, and everything behind the login goes through the token, because a domain doesn’t prove who someone is.
With a set of token values and a domain. There is no new code path and no fork of the component library.
Preventing that is the point of the design. Isolation doesn’t depend on every query carrying the right filter, and a query with no tenant context gets no rows back.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.