Four kinds of user, one database, and none of them may see each other

A lab is not one user. There is the lab administrator who owns the account, the employees who register patients and enter results, the collection centres that take samples off site under the lab’s name, and the platform administrator above all of them. Each sees a different slice of the same data, and a leak between two labs would be a leak of patient records.

On top of that, every lab wants its own test templates, its own report layout, its own pricing and its own commission rules. Building that as configuration rather than as forks was the whole design problem.

Scoping enforced in one place, features layered on top

Each actor type authenticates through its own token header and resolves to the same lab through a single permission layer, so scoping is decided once instead of being re-implemented in every view. Employees gate on a permissions object, collection centres on a separate feature-permission object, and subscription tier gates the advanced features. Tenancy itself is resolved from the subdomain in middleware.

Test templates are global and read only to labs, which then adjust them through override layers rather than copies, so a platform-wide correction reaches every lab that has not deliberately overridden it.

On that base I built the commercial layer the labs actually asked for: partner-lab panels with billing and settlement statements, marketing manager commissions with an automatic ledger, per-employee commission on the receipts they create, discount authorisation with per-test and per-day ceilings and a full audit trail, and receipt limits as rolling thirty day quotas that reset themselves.

It runs as a Docker Compose stack on EC2 behind nginx, with Celery and Redis for subscription reminders, nightly database and media backups, and login throttling.

What it does in production