Custom ERP or off-the-shelf for a wholesaler?

We built a custom ERP for a fabrication and wholesale company in India over about two years, from around 2012 to 2014. It was our first large ERP. It’s more than a decade old, and the product market has moved a long way since, so don’t read it as a claim about today’s options. We’re using it because it shows where a wholesale business’s logic really lives.

The system covered quoting with material and labour costing, production tracking, multi-location inventory and SKUs, dispatch, VAT billing and accounting, management reporting, and a login where customers placed orders directly.

“ERP” bundles very different problems. Some are the same in every company, and some are specific to how yours operates. Here is how we would look at that same list if we were advising a similar business today.

The table is a starting opinion, not a verdict. The pattern is that accounting rarely repays custom work, while quoting often does, because a fabricator’s costing is where its experience and margin sit.

• Where do mistakes cost you money today? Under-quoted jobs, stock counts that disagree with the floor, and late invoices each lead to a different first project.
• Who holds the rules in their head? If one estimator prices everything from memory, write those rules down before you evaluate any software.
• What must connect? Check your accounting system, your bank and your e-invoicing or tax requirements.
• Can you run a product’s standard process? Changing how you work can be cheaper than customising software, unless that way of working is why customers stay.
• Who will own a custom system in ten years? Software that lasts needs people, updates and documentation long after launch.

A company can’t wait two years for its first benefit, so we would plan a new build to release one useful module into daily use and then extend it. The order-to-cash and production patterns we first worked out on that project are ones we still use, which is also a reminder that the business logic can outlast the technology it was written in.

A second point is that tax is a moving target. A system built around one tax regime needs rework when the rules change, which is another reason to keep tax and ledgers in a maintained product, and to keep your custom code focused on what is yours. If you already run an ageing custom system, see how we approach upgrades before assuming it has to be replaced.