Keep a multi-tenant model coherent
Identity, entitlements, data, and time must remain coherent across use cases, without local shortcuts creating a competing second model.
Emovanti: making architecture decisions for a multi-tenant SaaS ahead of beta
This internal project formalizes Emovanti's architecture and product decisions. Its pre-production environments are deployed, its beta is in preparation, and it has no production users.
The point is not to document choices after the fact: it is to make the rules that protect identity, data, entitlements, and time explicit before the product grows.
Decide before conventions become constraints
In a multi-tenant SaaS, an approximation about identity, authority, or data location rapidly becomes product debt. Here, decisions are the contract between the domain, the platform, and future changes.
The problem to solve
Decisions that protect product boundaries
Each choice fixes a rule legible to product and engineering, rather than an implicit convention hidden in a table or screen.
One fleet-scoped identity of record
The record vehicle belongs to its owning fleet tenant. VIN and registration are matching signals, never global keys; an overlapping second vehicle model is retired.
Three mechanisms for three readings
Logs, audit trail, and actor timeline have distinct owners and readers. The product-facing timeline never queries raw audit rows.
Retention and residency decided by domain
Data areas have target retention windows, with an audit archive. A fleet chooses its zone from its market at creation, never changes it implicitly, and its files follow that zone; every market maps to Europe at launch.
Plans, entitlements, and time under one rule
One fleet concept carries the plan and its capabilities through a single entitlement resolver; no subscription means the Free plan. Instants are stored and compared in UTC, assignment authority uses half-open intervals, and display uses the user's or fleet's time zone.
A register that connects decisions to the product
The ADRs and dated register prevent critical rules from depending on individual memory. They give a starting point to challenge a decision, explain a constraint, and evolve the product without undoing its boundaries.
Decide, then make the rule usable
The decisions cover the record identity, trace reading, retention, residency, entitlements, and authority instants: rules that keep use cases coherent where they intersect.
The published markers
They describe the product's decision discipline, not a promise of availability or scale.
- ADRs
- 29 architecture decisions.
- Register
- 112 dated product decisions.
- Identity
- One vehicle record, fleet tenant by fleet tenant.
- Time
- UTC to decide, user or fleet time zone to display.
What this study establishes
A multi-tenant SaaS holds together better when its domain invariants become written, testable, understandable decisions before it scales.
Make product invariants explicit before multiplying them through the code.
A record model, an authority rule, and a reading suited to each audience prevent a product from adding exceptions when it should preserve its boundaries.