Demo-ready is not tenant-ready
Many MVPs store everything in one pile until a second customer appears—then data leaks, broken queries, and panic indexes follow. If you are building society software, EdTech cohorts, or white-label client portals, tenancy belongs in the design from week one.
The pattern that works for most early SaaS
Start with a shared database + tenantId on every business document. It is simpler than database-per-tenant and enough for most Indian SaaS products until compliance or scale forces a split.
- Every query filters by
tenantId - Compound indexes start with
tenantId - Auth tokens carry tenant context server-side—never trust the client alone
- File uploads and caches are namespaced by tenant
Where products like Taniyur need stricter boundaries
Society platforms handle visitor logs, phone numbers, and payments. That raises the bar: role checks, audit trails, and careful admin impersonation. See the product context on taniyur.com and the guide to society management software in India.
When to split tenants
Split databases or clusters when a customer needs isolation for compliance, noisy-neighbor risk is real, or restore requirements differ. Until then, shared tenancy with ruthless query discipline is usually faster and cheaper.