One platform, many products: how I think about multi-tenant SaaS

When you build more than one product with a small team, the temptation is to start each one from a blank folder. That path is comfortable for a week and expensive forever: you re-implement authentication, organizations, billing, and notifications every single time, and each copy drifts. The alternative is to treat those concerns as a platform and let products sit on top of it.

The shared core

A handful of concerns show up in almost every product I build. They belong in one place, versioned once, and reused everywhere:

• Identity & authentication — who the user is, across web and mobile.
• Organizations & tenancy — the boundary every other record is scoped to.
• Billing — plans, subscriptions, and entitlements.
• Notifications — email and push, behind one interface.

A new product then becomes mostly new domain logic — listings and bookings for a property platform, courses and lessons for a learning platform — rather than new plumbing. That is what makes shipping several products realistic without a large team.

Tenancy without a database per customer

The cheapest isolation model that still holds up is organization-scoped, row-level tenancy: every record carries an organization, and every query is scoped to it. You avoid the operational weight of a database per tenant while keeping a hard boundary in the data model. The organization becomes the unit you reason about for access, billing, and data ownership.

The line I try not to cross

The discipline is keeping product-specific logic out of the core. The core should not know what a 'booking' or a 'lesson' is. The moment it does, every product inherits every other product's complexity, and the thing you built to move faster starts slowing you down. Shared code earns its place only when it is genuinely shared.

Done well, this is invisible: a new product feels fast to start because most of the hard, boring infrastructure already exists and is battle-tested by the products already using it.