"Can we turn our system into a SaaS product and sell it to other firms?" It's one of the most common questions we get from enterprises sitting on a system that already works. The hard part isn't the idea — it's the isolation model, and that decision is almost impossible to reverse later.
Here's the checklist we work through before any schema is touched.
Choose the isolation model first
Shared schema with a Tenant ID column is the pragmatic default — cheaper to run and easier to maintain than database-per-tenant. But it puts the entire burden of separation on your code. Every query, every report, every background job must be tenant-scoped. One missing predicate and Tenant A sees Tenant B's data — which under POPIA is a reportable breach, not just a bug.
Enforce isolation where it can't be forgotten
We push tenant filtering down into row-level security and scoped data-access patterns, rather than trusting that every developer remembers the WHERE clause. Defence in depth, because humans forget.
Design onboarding as a product, not a script
Provisioning a new tenant — seed data, default config, admin user, isolation checks — has to be a repeatable, automated path. If standing up a tenant needs an engineer, you don't have a SaaS yet.
Plan for the noisy neighbour
Shared infrastructure means one tenant's heavy month-end run can starve everyone else. Know how you'll detect it, and where you'll throttle, before a client feels it.
Build the kill switch early
Suspending, exporting, and fully deleting a single tenant's data — cleanly, on request — is a POPIA obligation and a question enterprise buyers will ask. Retrofitting it is painful.
Multi-tenancy is an architecture decision dressed up as a feature. Get the isolation model right on day one, because day 200 is far too late to change it.