Tenant isolation across 45+ data models.

The platform was moving upmarket. Prospective enterprise customers wanted to know how the application kept one customer’s data separate from another’s, and how the team checked that those protections still worked as the product changed.

The job was to make tenant isolation consistent across the application and give the team tests they could use to demonstrate it.

I rolled tenant isolation through more than 45 data models, so queries for one customer’s records stayed within that customer’s account.

I also designed an access-rules system with safe defaults. The rules were set up during onboarding, and newly created objects were isolated by default. Engineers didn’t have to remember to configure access separately for each new object.

To keep those protections in place, I built reusable test scaffolding and checks that ran in CI. These tested the authorization policies so that later changes could be checked for regressions.

The rollout took several quarters. I broke the work into backward-compatible changes that the team could ship incrementally while existing customers continued using the product.

The application enforced tenant isolation through its access rules, with tests in CI to check that it stayed in place as the code changed.

When a prospective customer asked about isolation, the team could explain how the rules worked and show the tests that checked them. That gave them concrete evidence to use in enterprise security reviews.