A multi-tenant HR & payroll platform, built for European SMBs.

The naive approach to salary structures is to store a reference: “employee X is on salary structure Y.” Then when payroll runs, you resolve the components live. This breaks the first time someone updates the structure mid-year — historical payroll silently changes.

Instead, when a salary structure is assigned to an employee, Employrax resolves every component value and writes them into an immutable snapshot table (employee_salary_components). Future structure edits don’t touch historical assignments. Payroll for April 2024 still computes the way April 2024 was promised — even if the underlying structure has been revised three times since. This is the kind of decision people regret not making on month eighteen.

Microservices solve organizational scaling problems, not technical ones, and Employrax is built by one person right now. Picking microservices on day one would have been LinkedIn-driven architecture — bad operationally, bad financially, and slow to ship.

Instead I designed a modular monolith with strict domain boundaries: nine modules (Platform, Auth, Tenant, Organization, Employee, Compensation, Payroll, Notification, Audit), each with its own actions, services, queries, policies, and HTTP layer. Cross-module shortcuts are forbidden by convention. The result: I get fast local development and one deploy target today, and if any domain becomes genuinely heavy in the future — payroll processing is the obvious candidate — it can be extracted without rewriting the rest of the system.

Payroll engines that hardcode country logic become unmaintainable. Payroll engines that try to be “country-agnostic” from day one ship nothing. The middle path: a TaxEngineInterface contract, an IndiaTaxEngine concrete implementation, and dedicated calculators for each statutory rule (PF, ESI, Professional Tax, TDS).

Country-specific logic stays isolated in Engines/India/. When the time comes to add a second geography, the work is well-bounded — a new engine implementation, not a system-wide refactor. Form 16 generation, India’s annual tax certificate, lives in the same isolated module.

Multi-tenant SaaS has one truly dangerous bug class: a query that forgets to filter by tenant and silently leaks one customer’s data to another. The defence is structural, not careful: a TenantAwareModel base class that automatically applies a TenantScope to every query, and a TenantContext resolved by middleware before any business code runs.

This means a junior developer (or an AI agent) cannot accidentally write a cross-tenant leak without first explicitly bypassing the safety. The few global tables that genuinely need to be tenant-free extend BaseModel instead. The default is safe; the dangerous path requires intent.

A multi-tenant SaaS data model has dependencies that map directly onto its onboarding flow. Get the migration order wrong and you ship a system that can’t actually bootstrap a real customer. The migrations are deliberately ordered into six phases — platform identity, tenant and organization, employee foundation, compensation foundation, payroll foundation, audit and platform control — totalling 35+ tables in a strict sequence.

This isn’t bookkeeping; it’s a forcing function. It guarantees that the database model can be built up incrementally on a fresh environment, that fixtures and seeders work, and that disaster recovery has a defined replay order. It’s documentation that the database itself enforces.