Follow Us

Architecture

ERP & Multi-Tenant SaaS

Domain modelling for systems that outlive their first version — multi-tenancy, effective-dated records, and schemas that survive the rules changing.

ERP & Multi-Tenant SaaS

What I build

Business systems where the hard part is the domain, not the screens: ERP modules, multi-tenant SaaS, HR and payroll, inventory, billing. Software whose rules change every year and whose data has to stay correct anyway.

The reference point is BYKII — a multi-tenant ERP whose PostgreSQL design runs to roughly 200 tables across HR, payroll, operations and finance, with tenant isolation, effective-dated records, and field-level AES-256-GCM encryption on personal data.

How I work

Domain modelling comes first, and it is done with your operations people rather than from a specification. I need to know how the business actually behaves at month-end, what the exceptions are, and who is allowed to override whom, because that is precisely where naive schemas break.

Effective dating is the default for anything with a history. A salary, a price or a policy is not one value; it is a value with a period of validity. Getting that right at design time is the difference between a clean audit and a rebuild.

What you get

  • A tenancy model chosen deliberately — shared schema, schema per tenant, or database per tenant — with the reasoning written down.
  • An auditable history: who changed what, when it took effect, and what the record looked like before.
  • Role and permission design that survives a reorganisation instead of being patched after every one.
  • A privacy posture that holds up: encryption at rest for personal data, retention rules, and consent handling aligned with Egypt PDPL Law 151/2020 and GA4 Consent Mode v2.
  • Operational reporting that management will actually open — dashboard work at IT-Plus improved reporting efficiency by 30%.
  • Migration paths from whatever you run today: spreadsheets, an ageing system, or several systems that disagree with each other.

The stack

PostgreSQL first, with Prisma or Eloquent depending on the team. NestJS or Laravel for the application layer, Angular or React for operator interfaces, and Nx or Turborepo when a monorepo is the honest answer to shared code — on an Angular monorepo at Champions Global that approach removed 35% of duplicated frontend logic.

A good fit if

You are turning an internal tool into a product for many customers, replacing a system nobody dares touch, or designing a schema you will have to live with for the next five years.