Overview
infithra is a multi-tenant HRMS platform I helped build from an empty repository into a system running the full employee lifecycle — onboarding, payroll, leave, attendance — for thousands of daily users across dozens of UAE-based companies, each with its own policies and Labour Law obligations.
I joined before the first schema existed. What follows is the technical story: the decisions that held up, the ones that had to be revisited, and what building enterprise software from zero actually looks like from the inside.
The Business Problem
The HR landscape in the UAE requires specific regulatory adherence. Businesses needed a unified platform that could:
- Handle multiple distinct organizations securely within a single deployment.
- Calculate highly complex payroll structures, including gratuity, overtime, and multi-currency allowances.
- Provide a seamless, fast, and unified experience for both HR administrators and employees.
Founding / Lead Engineer. There was no legacy code to inherit and no prior architecture to defend — every early call on data isolation, permissions, and deployment became the standard the rest of the platform would be built on. I later grew and led the 6–8 engineer team that took the platform from first tenant to production scale.
The platform now runs 800+ production APIs, sustains 99.9% uptime, and handles region-specific payroll and compliance for dozens of tenants without a single reported cross-tenant data leak — the one failure mode that would have been unrecoverable for a product built on this model.
Technical Challenges
Multi-tenant Isolation
Serving hundreds of companies from one database required bulletproof isolation to prevent cross-tenant data leaks.
Complex Authorization
Simple role-based access wasn't enough. We needed a hybrid RBAC and ABAC system to allow custom permissions per module per tenant.
API Scale
Delivering over 800+ production APIs while maintaining response times under 200ms.
Dynamic Payroll Engine
Handling intricate UAE Labour Law requirements required a highly scalable calculation engine capable of processing multi-currency allowances and gratuity concurrently.
Architectural Decisions
Cloud Infrastructure
AWS
Leveraged the AWS ecosystem to build a scalable and secure foundation—utilizing EC2 for compute, RDS for managed databases, S3 for object storage, Cognito for authentication, and SSM for secure parameter management.
Backend Architecture
Node.js & PostgreSQL
Selected Node.js for its robust ecosystem and scalability. We utilized PostgreSQL for relational integrity, which is critical for financial and HR data.
Caching and Queueing
Redis
Implemented Redis to handle session management and background task queueing (e.g., end-of-month payroll processing for thousands of employees simultaneously).
Frontend Strategy
Angular & Next.js
Used Angular for the core multi-tenant platform due to its robust architecture and state management, and Next.js for the heavy-lifting admin dashboards where performance and rapid load times were paramount.
Key Takeaways
In enterprise software, data architecture is destiny — a mistake made in the tenant model on day one is a mistake every future feature has to work around. What surprised me most wasn't the payroll math or the permission matrix; it was how much of “architecture” is really about writing down defaults so a growing team doesn't have to relitigate the same decision five different ways. I over-built a few abstractions early that never got used, and under-built others that had to be rewritten under load — both are part of learning what actually needs to be generic versus what just needs to work.