Designing Multi-Tenant Backends With Both Ownership and Team Access
A practical architecture pattern for systems where one user can own, join, and operate multiple organizations.
Apr 14, 202610 min read21
Command Palette
Search for a command to run...
Series
Building Multi-Tenant Systems That Match the Real World
A practical, architecture-first series on building multi-tenant backends that survive real organizational behavior — ownership, teams, roles, scoped permissions, and two planes of authority. Generalized patterns you can reuse in any SaaS, marketplace, agency, healthcare, or internal tool. NestJS-flavored, but the model travels.
How to Model Teams Inside a Multi-Tenant Product
Once you have the tenant boundary, the next question is what lives inside it. This is how I modeled teams with roles, invitations, and lifecycle states that match real organizational behavior.
Jun 2, 202612 min read
When "Admin" Means Two Different Things: Platform vs Organization Authority
The word "admin" hides a fault line. On one side is authority over the whole platform. On the other is authority inside a single organization. This is how I keep those two planes from leaking into each other.
Jun 2, 202612 min read
Turning a Permission Model Into a Guard
A permission model that lives only in the database does nothing. This is the runtime layer, a declarative decorator and a guard that turns "who can do what" into an enforced answer on every request, without scattering authorization logic through your handlers.
Jun 2, 202612 min read
Two Gates: Authorization vs Entitlement
"Can this user do it?" and "does their plan allow it?" are two different questions. Most systems answer only the first, then bolt the second onto it badly. This is how I keep authorization and entitlement as two independent gates — and why mixing them is a mistake you pay for later.
Jun 2, 202614 min read
Onboarding Is a State Machine, Not a Boolean
A tenant is not "set up" or "not set up." It moves through ordered steps, can pause mid-flow, and must survive a refresh, a dropped payment, or a user who comes back three days later. This is how I model onboarding as a state the backend owns, and a guard that gates the rest of the product until that state says go.
Jun 2, 202614 min read