Multi-Tenant ERP Modules

The problem

An ERP is several businesses’ worth of rules sharing one database. Finance, HR and inventory each have their own vocabulary and invariants, and every one of them has to hold per tenant: one customer’s ledger, staff and stock must never leak into another’s, however the reports join them. The failure mode isn’t a crash; it’s a module that quietly assumes it’s the only one, or a query that forgets which tenant it’s serving.

What I built

I developed the finance, HR and inventory modules in Laravel and Python, with a modular, domain-driven architecture: each module is organised around its own business area and rules rather than around the framework’s folders, so the three can evolve without stepping on each other.

Alongside the modules I built an API integration layer connecting the ERP to the internal CRM and to external partner systems, so data crossing those boundaries goes through one place built for it.

The result

The large transactional databases behind it got the unglamorous attention they needed — query and schema optimisation that cut average query times. It’s also where I learned the lesson I’ve applied on every platform since: draw the boundaries along the business, and let the framework serve them rather than decide them.