Multi-Tenant SaaS Architecture: The Decisions You Cannot Undo Later

The advice to "not over-engineer the MVP" is correct for almost everything in a SaaS product. It is wrong for exactly three things. Tenancy, identity and billing boundaries are load-bearing — every table, every query and every permission check ends up depending on them, so changing them later means rewriting the parts of the system you least want to touch.

Decision One: The Tenancy Model

Shared database with a tenant column is the right default for most products. It is simple, cheap and scales further than people expect. Database-per-tenant becomes worth its operational cost when you have genuine data-residency requirements, enterprise customers contractually requiring isolation, or wildly uneven tenant sizes where one customer would otherwise degrade everyone.

Whatever you choose, enforce tenant scoping at the lowest possible layer — row-level security in the database, or a repository layer no query can bypass. Enforcing it in application code means every future developer must remember, and eventually one will not. A cross-tenant data leak is the one bug that can end a B2B SaaS company outright.

Decision Two: Identity and Org Structure

Model users and organisations as separate entities from day one, with a membership relationship between them, even if your first hundred customers are single-user accounts. The moment one customer says "we need three people on this account" or "our agency manages five client workspaces", a user-owns-everything model has to be unpicked from every query in the system. The membership model costs an afternoon at MVP. Retrofitting it costs a quarter.

Decision Three: Billing Boundaries

Decide early what a subscription attaches to — the user or the organisation — and what your metered units are. You do not need billing logic built at MVP, but you need to be recording the events you will eventually bill on. Usage data cannot be reconstructed retroactively. Teams that add metering after launch discover they must either bill inaccurately or wait a full cycle for clean data.

What You Can Safely Defer

Almost everything else. Microservices, event sourcing, Kubernetes, multi-region, read replicas, caching layers — none of it needs to exist at MVP, and adding it early makes the product harder to change during the phase when you need to change it most. A well-structured monolith on managed infrastructure carries most SaaS products further than the architecture blogs suggest. Get the three irreversible decisions right and stay boring about the rest.