Multi-tenant SaaS architecture — where multiple customer organisations share a single platform instance with full data isolation between them — is one of the most commercially powerful patterns in software. It's also one of the most demanding to build correctly. Here's our honest take on when it makes sense to build from scratch, and when to reach for an existing platform.

The Case for Building

There are specific conditions where building your own multi-tenant platform is the right call. The first is when your domain requirements are genuinely complex and don't map to any existing SaaS product — as we found when building the NDIS provider platform, where compliance logic and data relationships were specific enough that no off-the-shelf tool could accommodate them.

The second is when the per-seat economics of existing platforms don't work at scale. If your target market is price-sensitive and you need to service hundreds of accounts at a unit economics that makes SaaS margins viable, building your own platform is often the only path.

• Domain complexity that no existing product handles correctly
• Pricing model that requires owning the infrastructure to be commercially viable
• Need for deep customisation per tenant that SaaS platforms charge enterprise rates to support
• Data residency or compliance requirements that rule out most hosted SaaS solutions
• IP value — the platform itself becomes a defensible asset, not a monthly expense

The Architectural Decisions That Matter

The most consequential decision in multi-tenant architecture is how you implement data isolation between tenants. There are three primary models: shared database with row-level security (RLS), separate schemas per tenant in a shared database, and separate database instances per tenant.

For most early-stage SaaS products, shared database with RLS — as implemented via Supabase or directly in Postgres — is the right starting point. It's operationally simple, performs well up to hundreds of tenants, and isolates data at the database level rather than relying solely on application-layer checks.

"

The biggest architectural mistake in multi-tenant SaaS isn't choosing the wrong isolation model — it's implementing isolation inconsistently, leaving gaps that only appear when you look for them.

What Most Early Builds Get Wrong

• Treating tenancy as an afterthought — bolting on isolation logic after the data model is built
• Inconsistent RLS policy coverage — some tables isolated, others accessible across tenants
• No tenant-scoped logging or audit trail — makes debugging and compliance impossible
• Shared background job queues without tenant isolation — one tenant's heavy workload affects others
• No plan for tenant offboarding — data export, account deletion, and GDPR compliance are non-optional

When to Use an Existing Platform

If your use case maps well to an existing vertical SaaS product — project management, CRM, helpdesk, HR — using that product is almost always faster and cheaper than building. The cost of building and maintaining a multi-tenant platform is substantial. It requires ongoing engineering investment, infrastructure management, and security attention that existing platforms have already absorbed across their customer base.