Why Multi-Tenancy Is an Architecture Problem, Not Just a Config Setting

A software team building a low-code platform discovered that a seemingly simple client request—letting four subsidiaries share one system while keeping their data separate—exposed deep architectural complexity. Multi-tenancy actually encompasses three distinct concerns: deployment isolation, data partitioning, and configuration customization, and most platforms quietly assume these can be bundled together. The challenge intensifies on low-code platforms because the application's own structure—fields, workflows, permissions, and scripts—is also tenant-scoped data, not just business records. A script written by one subsidiary could inadvertently access another's data, not due to malicious intent but because the boundary was never enforced at the runtime level. The core lesson is that tenant isolation cannot rely on developers remembering a where clause; it must be enforced systematically by every layer of the platform's runtime.