The pitch for a full ERP is always the same. One system, every department, everything talks to everything. It is a genuinely good end state. The problem is the route — it asks a business to change how finance, stores, HR and purchase all work, in the same quarter, while still running the business.
Most of the stalled implementations I have been called in to look at failed in the same place. Not the software. The changeover. Six months in, three departments were on the new system, two were still on the old one, and everyone was double-entering to keep both alive.
Pick the process someone maintains by hand
There is usually one process in a business that a specific person is holding together with a spreadsheet and their memory. They know which rows are stale. They know the one formula that must not be dragged down. If they take leave, that process stops.
That is your first module. Not the one the vendor demo starts with — the one with a human bottleneck. It has three things going for it:
- The requirement already exists, written down, in the spreadsheet. You are not designing from scratch, you are reading it off.
- The person who maintains it is motivated to help. They want it gone.
- The value is measurable within weeks, which is what buys you the budget for module two.
On one project it was stock reorder. Someone was checking 974 items against their reorder level by eye, every week, and typing a purchase order. The module that replaced that ran the same check in a second and generated a PO of 84,713 units — a little over ₹18.5 lakh — calculated instead of typed. That single screen is what made the rest of the platform an easy conversation.
What "one module" should still include
Starting small does not mean building a throwaway. Even the first module needs the boring foundations, or module two will mean rewriting module one:
- One user list. Users, roles and permissions belong to the platform, not the module. Get this right once and every later module inherits it.
- Real import. Whatever data lives in the spreadsheet has to come in on day one, in bulk, including the history. A module that starts empty gets abandoned.
- Export back out. Excel and CSV out of every list screen. It is how people check your numbers against theirs, and it is how they stop being afraid of the change.
- An audit trail. Who changed what, when. You will need it the first time two people disagree about a number.
That is roughly two extra weeks of work on the first module and roughly zero on every one after it.
Then let usage decide the order
The second module should be chosen by the people using the first one, not by the plan you wrote before you had any.
Once a module is live, the requests arrive on their own — and they are better than anything from a planning workshop, because they come from someone who has now used the thing. On the platform that started as a stock reorder screen, the order ended up being: purchase approvals, then item master, then work logs, then recruitment. None of that sequence was decided up front. It came out of eighteen months of people asking for the next obvious thing.
When a full ERP genuinely is the right call
Module-first is not always right. Go straight to the full system when:
- You are replacing an existing integrated system and cannot run two in parallel — the cutover has to be one weekend.
- A regulator or auditor requires the whole chain in one place from day one.
- The processes are so interlocked that one module in isolation does nothing useful — some manufacturing setups genuinely are like this.
Outside of those, the risk profile of a phased build is simply better. Each module is small enough to abandon if it turns out to be wrong, and nothing is worth more than a few weeks.
The seven modules on this site all arrived this way. Each one was a single client's specific problem first, and only became a module because the next client had the same problem. See what is ready today, or read how they got built.