The problem
Hexavera is built for enterprises of more than 1,000 employees that run access control, attendance and workforce operations across many sites. They need one platform that works in the cloud and on premises, keeps every tenant's data apart, and talks to door controllers that were never designed to face the internet.
Role
Architecture and engineering: the identity platform, the tenant model, the gateway to physical devices, and the quality systems the team builds against.
Key decisions
- Our own identity provider. Cloud and on-premises deployments need the same sign-in, so the platform runs its own OpenIddict server instead of depending on a hosted one. Each person's token carries one audience, and service clients authenticate with mutual TLS.
- Tenant isolation from the database up. Every tenant gets its own schema, created before the tenant's row exists. When the tenant or the token cannot be checked, the answer is 503, never 401: a dependency failure must not look like a signed-out user.
- Trust in tiers. Devices, the on-site gateway and the cloud are separate trust tiers. The device tier is the customer's choice and never a silent default; everything above it is protected to the maximum.
- One repository, several solutions. Repository permissions are the only need-to-know boundary Azure Repos offers, and nobody has to be kept from part of the code yet, so the product line stays in one repository with several solution files that share projects. Splitting into repositories remains the step for when that changes.
- No compatibility before the first release. Every local database can be dropped and rebuilt from migrations and seeds, and code that accommodates old data is treated as a defect.
Where it stands
In active development ahead of its first release. The identity platform comes first; the access control product follows it.