Name the boundaries before they harden

Decide what a tenant is, which data belongs to it, who can change configuration and how support staff see customer records. These choices affect pricing, onboarding, reporting and the support model, not only the database schema.

Make isolation testable

Tenant isolation should be verified with tests that attempt cross-tenant reads, writes and exports. The same applies to permission changes, shared configuration and reporting access. A boundary that is only described in a design document is not yet a boundary.

  • Test access at the API and data layers, not only in the interface.
  • Record which roles can change entitlements and configuration.
  • Define what happens when a customer loses access or leaves.

Price and support the model you choose

Pooled, dedicated and hybrid tenancy carry different operating costs. Choose the model from the segment you are selling to and the support you can provide, then document the migration path for existing accounts.

In practice

Invest in clear boundaries and operating visibility before adding architectural complexity.

More on Product Thinking