The first rule of multi-tenant software: know whose data it is.

Multi-tenant software lets several organisations use the same application. That creates an obligation: one organisation's data must not become available to another because a query forgot a condition.

The first design discussion should be about that boundary, rather than how many users the system might eventually have.

Resolve the tenant from trusted context

A tenant ID supplied by the browser is a request, not proof of membership. Authenticate the person, check their access to the organisation, and apply that context to the operation.

Keep the rule consistent across lists, individual records, exports, file downloads, and background jobs. A secure dashboard does not help if its export endpoint skips the same check.

Put isolation into the data model

For a shared database, tenant ownership should be explicit. Constraints and indexes should reflect it. Depending on the database and application, row-level security can provide another layer, but it needs careful connection and policy handling.

Separate databases are another option with different operational costs. There is no useful universal answer without understanding the product's requirements.

Remember the cache

A cache key needs the same separation as a database query. If a response varies by tenant or permission, the key and invalidation strategy must account for that variation.

The same applies to logs and analytics. Include enough context to investigate issues while keeping sensitive data out of places that do not need it.

Test the wrong organisation

Create two tenants in a test environment. Try to read, update, delete, and download the other tenant's records. Include guessed identifiers and background operations.

These tests are more valuable than a diagram that labels the system “secure”. Good boundaries are demonstrated by behaviour: a person gets the data they are allowed to use, and nothing beyond it.