The request that usually arrives
"We looked at three ERP products. None of them fit how we work. We want something custom."
Sometimes that is exactly right. More often the three products were evaluated by watching demos, and "does not fit" means the screens looked unfamiliar rather than the process is genuinely impossible.
That distinction is worth a lot of money, so it is worth being careful about.
What off-the-shelf is actually good at
A packaged ERP has had thousands of businesses find its bugs. The reports exist. The tax handling is maintained by someone else as rules change. When your accountant leaves, the replacement has
probably used it.
You get it in weeks, not quarters. Support is a phone number. Nobody on your side has to own the
architecture.
That is a strong offer, and any custom proposal is competing against it.
Where it stops being enough
Packaged systems assume a shape of business. When yours differs on something central, you find out
in one of these ways:
- Your process genuinely is the differentiator. Job-work heavy operations, unusual costing, a
pricing model that depends on grade and lot rather than SKU. If the thing that makes you competitive
is exactly the thing the software cannot express, you are being asked to become average to fit the
tool. - The workaround economy has taken over. The real test is not what the ERP does — it is how many
spreadsheets sit around it. When the actual production plan lives in Excel and the ERP is where
someone types it in afterwards, the system is documentation, not software. - Per-user licensing has become the constraint. Deciding not to give the stores supervisor access
because of the seat cost is a business decision being made by a pricing page. - Integration is impossible rather than inconvenient. Your machines, your weighbridge, your
customer's portal. If the closed system cannot talk to them, the data entry that fills the gap is a
permanent staffing cost.
The middle option people forget
Custom versus packaged is a false binary, and the third answer is often the best one.
Keep the packaged system for what it is good at — accounts, statutory reports, the parts that must follow rules you do not control. Build custom only around the piece that is genuinely yours, and make the two talk.
A manufacturer might keep Tally for accounts, run a standard purchase and stores module, and build one custom application for job-work tracking because that is the part nobody sells software for. The custom piece is small, focused, and finished in months rather than years.
This depends on the systems being able to exchange data, which is why API-first
thinking matters more than the build-versus-buy argument
itself.
The honest test
Five questions. Score them before anyone writes a proposal.
- Is the process that does not fit central to how you make money, or is it just habit? Plenty
of "we have always done it this way" is genuinely valuable. Plenty is not, and a packaged ERP
forcing a cleanup is a benefit disguised as a constraint. - How many people would use the parts that need to be custom? Ten people doing something
unusual justifies software. One person doing something unusual usually justifies a better
spreadsheet. - Will this process survive five years? Building custom software for a process that changes
annually means paying for it annually. - Do you have someone internally who will own it? Custom software with no owner drifts.
Somebody has to decide what version two does. - What is the cost of the current workaround? Count the hours, the errors, the decisions made
on stale numbers. If the workaround costs little, the software will not pay for itself no matter
how well it is built.
Mostly ready-made answers: buy, configure lightly, move on. Mostly custom answers: build, but
narrow.
How to build it if you build it
- One module first, where the pain is worst. Not a phased plan on paper — an actual working thing
in production before module two starts. If the first module does not earn its keep, you have learned
that cheaply. - Build the process you have, not the one in the SOP. Every factory has an official process and a
real one. The real one usually exists because the official one did not survive contact with a rush
order. Software that implements the official version gets bypassed within a month. - Watch the floor before designing screens. An hour standing next to the stores clerk beats a week
of requirement meetings. What people actually do differs from what they say they do, not because
anyone is lying but because the workarounds have become invisible to them. - Decide what stays. Accounts almost always stays. Payroll frequently stays — statutory rules
change and you do not want to own that. See the payroll compliance
post for why that one is particularly unattractive to
build. - Plan for handover from day one. Documentation, and more than one person who understands it. A
custom ERP that only one developer can change is a liability wearing an asset's clothes.
The failure mode to avoid
The most expensive ERP outcome is not choosing wrong. It is trying to replace everything at once.
Purchase, stores, production, quality, dispatch, accounts, payroll — a big-bang cutover across all of it means every department learning a new system in the same week, while the old one is switched ff and the business still has to ship. Problems arrive together and nobody can tell which system caused what.
Module by module is slower on paper and faster in practice, because each piece proves itself before the next one starts.
What to do next
Before deciding, spend a day counting the workarounds — every spreadsheet, every register, every number retyped from one screen into another. That list is the actual requirement document, and it usually shows the problem is narrower than "we need an ERP".
Send us that list and we will tell you honestly which parts need building and which
parts a configured off-the-shelf system already handles. Sometimes the answer is that you do not need us for most of it.
More on custom software for
operations.
