Isolation you can
actually defend.

Tenant isolation enforced only in application code works right up until the one query that forgets the tenant filter. That query will be written eventually, by someone in a hurry, and the failure mode is one customer seeing another customer's data — the category of bug that ends contracts rather than generating a ticket.

So isolation belongs at the data layer, where forgetting is not an available option. Which mechanism fits depends on the shape of the product and how much per-tenant variation it has to absorb, and that is a specification decision with real consequences rather than a preference.

Retrofitting tenancy onto a schema that assumed one customer is among the more expensive migrations in software. Every table needs a tenant key, every query needs revisiting, and the data already in production has to be assigned without downtime. If multi-tenancy is plausibly in your future, deciding now costs a conversation; deciding later costs a quarter.

Per-tenant configuration is the other half — branding, feature availability, limits, regional settings — built so a new tenant is a record rather than a deployment.

What you get

• Tenancy model chosen and documented with its trade-offs
• Isolation enforced at the data layer, not only in application code
• Per-tenant configuration, branding and feature flags
• Access model covering users belonging to multiple tenants
• Isolation tests that fail loudly if a boundary is crossed

Not included

• Ongoing support retainer unless contracted separately
• Third-party licence fees