saas-mvp
Multi-tenant SaaS: architecture decisions to make before expansion
The product begins serving another business, and a question emerges: what prevents it from seeing the first customer's records? A customer-name column is not the answer.
The product begins serving another business, and a question emerges: what prevents it from seeing the first customer's records? A customer-name column is not the answer. Multi-tenant software must establish how organisation identity follows each protected request, operation and resource. Verify that boundary before expanding features.
Map the organisation boundary
Include records, files, exports, search and background jobs. For each resource, identify membership and the role permitted to read or change it. Hiding a button does not stop a direct server request. OWASP's multi-tenant guidance addresses isolation across multiple layers.
| Area | Authorisation question |
|---|---|
| Record query | Is organisation access checked before returning data? |
| File | Does object access follow the same boundary? |
| Export | Is its entire result scoped to user and organisation? |
| Cache | Are tenant-dependent responses separated? |
| Background job | Is context checked when the work executes? |
Test with two organisations
In a hypothetical environment, two organisations hold separate requests. Check whether a user from the second can read, change or export the first organisation's record by changing an identifier. Inspect files and work continuing after logout too. Perform this only in an authorised isolated environment, not by exploring real customer data.
Define invitations, role changes and user removal. Revoked access must stop at the protected operation rather than only disappear from navigation. Audit history should reconstruct actions without indiscriminately retaining private data.
Choose separation for the actual requirement
Shared databases, separate schemas and per-organisation databases have different operational, cost and recovery implications. No model is universally suitable. Risk, requirements and operating capacity guide the choice. An architecture label is not a security guarantee.
Through SaaS and MVP development, I can map tenants, roles and resources, implement server rules and test boundaries. For an existing product, modernisation can prepare an incremental migration.
Explain who contracts, who uses the application and which information is intentionally shared or isolated. Include files and integrations, not just tables. This allows the proposal to distinguish individual accounts from a multi-tenant operation and set real acceptance criteria.
Sources and further reading
Review your SaaS tenant boundaries
Describe current accounts, users and permissions. I can map tenant boundaries and test access before the product expands.
Review your SaaS tenant boundaries ↗