ERP modules
The seven below are already written and running in production, so they deploy in weeks. But they are not the limit — I build any module an ERP needs, and full custom ERP systems where nothing off the shelf fits.
Ready today
These seven exist as working software. Configured for your branches and roles, a module like this goes live in weeks rather than being written from scratch.
Attendance, leave, shifts and salary structure, with a Flutter app for staff who are never at a desk.
Item master and stock levels across branches, with reorder alerts before anything runs out.
Requisition to purchase order, following the real chain of command instead of a WhatsApp thread.
The full hiring pipeline, from a QR code on a job poster to a generated offer letter.
Revenue by unit and department, with an incentive engine finance can actually sign off on.
The full procure-to-disposal lifecycle across branches, with approvals that follow your hierarchy.
Operation theatre planning and ward handover, so the list is current wherever the team is standing.
Built to order
The seven above are simply the ones already written. An ERP is a wide thing, and there is no module I will not take on — these are the areas I work across. Nothing here is off the shelf; each is built to your process, on the same foundation as the ready modules.
Do not see your module here? That list is a sample, not a menu. If your business has a process nobody else has, that is exactly the kind of thing worth building properly. Describe it and I will tell you what it takes.
Full custom ERP
Some businesses do not want modules bolted onto a template. They want an ERP that matches how they actually run, because that way of running is their advantage. That is a larger project, and it is one I take on.
It gets built the same way as everything else here: one working module into production first, then the next, on your own server, with the source code handed over at the end.
No forcing your workflow into someone else's screens. If your approval chain has five steps and an exception for one branch, that is what gets built.
You do not sign off a two-year plan on day one. The first module goes live, proves itself, and the next follows — so the risk stays small at every stage.
Add every employee in the company if you want. You pay for the build, not a recurring fee that grows with your headcount.
One platform
Whichever you start with, the foundation underneath is the same — which is why adding the second module costs far less than the first.
A staff member added once appears everywhere they are meant to. No parallel user lists drifting out of sync between systems, no separate password for each tool.
Most clients begin with the module that hurts most — usually attendance or stock. The second module reuses the same users, the same branches and the same deployment, so it lands faster and cheaper.
Deployed on your AWS account or VPS with Nginx, SSL and scheduled backups. No per-user licence, no vendor holding your data, and the source code is handed to you.
Questions
A module deployed largely as-is, configured for your branches, roles and formats, is typically two to four weeks. If it needs real changes to match your process, expect four to ten weeks depending on how far it moves from the original.
A ready module is quoted as fixed scope, fixed price. Customisation is quoted after a scoping call, once it is clear what actually has to change. There are no per-user or per-year licence fees in either case — you pay for the build, and the software is yours.
Yes. The fastest way is a call where the closest module is walked through screen by screen, with your questions against your own process rather than a canned demo script.
Yes — that is a large part of the work. The seven ready modules are just the ones already written; sales, accounts, production, quality, dispatch, helpdesk, projects and anything else an ERP covers all get built to order. If your business has a process nobody else has, that is exactly the case for building rather than buying.
Yes. A full custom ERP is built the same way — one working module into production first, then the next, rather than a single large delivery at the end of a long project. You keep the server, the database and the source code throughout.
No. OT scheduling is healthcare-specific, but HRMS, inventory, purchase approvals, recruitment and asset management are sector-neutral and have been built for multi-branch operations generally. Manufacturing, distribution and service businesses fit the same foundation.
You keep everything — the server is yours, the database is yours, and the source code is handed over with documentation. Another developer can take it forward without needing anything from me.
Usually yes. Existing integrations have covered hospital information systems, CRMs, biometric devices, bank statement imports and Google Sheets. What matters is whether your current system exposes an API or a database you are allowed to read.
Describe the process in a few lines. If one of these covers it you will know quickly — and if none of them do, that is worth knowing too.
