A lot of early SaaS architecture decisions are reversible. Your choice of frontend framework, your hosting provider, even your database engine — painful to change, but doable. Multi-tenancy is different. Get the isolation model wrong early, and you're often looking at a full data migration to fix it once you have real customers on the platform.
Here's what tends to matter most when that decision gets made too late, or made without thinking it through.
Pick your isolation model before you have a reason to care
There are basically three common approaches:
- Separate databases per tenant — strongest isolation, most operational overhead
- Shared database, separate schemas — a middle ground, decent isolation, more manageable at scale
-
Shared database, shared schema, tenant ID on every row — cheapest to run, but a single missing
WHERE tenant_id = ?clause becomes a data leak
Teams often start with the third option because it's fastest to ship, which is a reasonable call for an MVP — but it needs to be a deliberate call, with a plan for what happens when a customer asks about data isolation for a compliance review, not a default nobody chose on purpose.
Billing logic doesn't stay simple
"We'll just charge a flat monthly fee" survives about as long as it takes your first customer to ask for annual billing, or your first enterprise prospect to ask for seat-based pricing. Building your subscription and billing layer with some flexibility from day one — even if you only expose one plan at launch — saves a rebuild later.
Usage-based metering, proration on plan changes, and failed-payment retry logic are all things that are much cheaper to design in than to bolt on.
An MVP is a test, not a smaller version of the product
The MVP trap is building a stripped-down version of the full vision instead of the smallest thing that tests your actual hypothesis. If your core bet is "teams will pay to automate X," the MVP should be almost entirely about X, with everything else — onboarding polish, settings pages, admin dashboards — deliberately rough.
It's uncomfortable to ship something that ugly, but the point is validated learning, not a portfolio piece.
Third-party integrations are a support burden, not just a feature
Every integration you add is now something you have to monitor, version, and support when the third party changes their API. Before adding an integration because a customer asked for it, it's worth checking whether it's a pattern (multiple customers need it) or a one-off (this customer specifically needs it) — those get very different levels of investment.
Cheap now, expensive later
None of these are novel ideas, but they're the ones that are cheap to get right early and expensive to fix later. Worth spending the extra week on the architecture conversation before writing the first migration.
For a closer look at how multi-tenant and subscription systems get built in practice, Web Matrix Lab's SaaS development page goes into more detail.
Top comments (0)