Every few months a retailer tells me they are going to build their own ERP. The pitch is always the same: the packaged systems are too generic, our processes are special, and by the time we finish paying licence fees and integration consultants we could have built something perfect. I have sat through this conversation with growing businesses, established retailers and one very confident start up. The outcomes have been consistent enough that I can describe them in advance.

Why building looks so attractive

The build case usually rests on three grievances. The first is price: licence fees plus implementation plus annual maintenance look outrageous against a developer day rate. The second is fit: every demo shows features the retailer does not need and misses the ones they do. The third is control: a bespoke system can change when the business changes, with no vendor roadmap to wait for.

All three grievances are real. The error is the conclusion. The comparison being made is between the full cost of a package and the apparent cost of building, and the build figure is always missing the years that follow launch. The procurement guidance maintained by the Chartered Institute of Procurement & Supply, in their knowledge library, makes the same point in blunter terms: total cost of ownership includes the decades, not the delivery date.

The real cost of building

A custom ERP is not a project, it is a permanent department. Every retail function you automate needs to be specified, built, tested and documented. Then it needs to be maintained while the business changes: new marketplace APIs, new VAT rules, new payment providers, new warehouse layouts. The team that builds the system becomes the team that keeps it alive, and they never shrink back to the size you budgeted.

I once reviewed a retailer that had built its own order management layer nine years earlier. The original build had cost them roughly what a mid range package would have cost. By year nine they employed five developers to keep it running, and the backlog of requested changes ran to four hundred items. Nobody could remember how the allocation engine worked, because the developer who wrote it had left in year two. The system was not a competitive advantage. It was a hostage situation.

There is also the question of audit and compliance. Retail ERP touches financial records, VAT reporting and customer data. The policy and regulatory commentary published by the British Retail Consortium regularly highlights how much of the compliance burden in UK retail now sits on systems, and a bespoke system carries all of that burden with no vendor to share it.

When custom build genuinely makes sense

Custom build is the right answer in two narrow situations, and both are about advantage, not cost.

1. The process is the product

If your stock allocation logic, your pricing engine or your returns processing is the reason customers choose you, and no vendor product can replicate it, then building it may be justified. The test is whether a competitor could buy the same result off the shelf. If they can, your advantage is not in the software.

2. You are building a product to sell

Software businesses that happen to be retailers, and retailers that intend to license their platform, have a different economic model. The development cost is an investment in a product with a market. That is a completely different calculation from a retailer building internal plumbing.

Notice what is missing from both situations: "our processes are unusual". In my experience most unusual retail processes are unusual because nobody has written them down, not because they are brilliant. The ten questions to ask before buying include a test for this: if you cannot explain a process in writing, you cannot build software for it and you cannot configure software for it either.

The hybrid middle ground

Between buying a package and building from nothing there is a space that most retailers never seriously explore: buy a platform with an extension layer, or buy the package and build only the genuinely differentiating module around it. This is the architecture discussed in the platform versus specialist comparison comparison, applied to build rather than buy.

The hybrid usually looks like a standard ERP core handling finance, purchasing and stock, with a custom module handling allocation, pricing or marketplace trading where the advantage lives. The core carries the compliance burden and the boring reliability. The custom module carries the competitive edge and stays small enough to maintain. This split also keeps the go live calendar realistic, because the risky part of the build is contained.

A decision checklist

If you are still tempted, work through these before commissioning any development:

  • Write the advantage down. One paragraph on why the custom system will make customers buy from you. If it mentions cost savings or convenience, that is not an advantage, that is a budget item.
  • Price the tenth year. Get a credible estimate of the permanent team size, then triple it for churn and knowledge loss.
  • Name the owner. Who in your business owns the code quality, the documentation and the disaster recovery for a system only you run?
  • Check the exit. If you build, you can never leave. If you buy badly, you can leave at a cost. Build removes the option, which is fine only when you are certain you will never need it.

If the checklist gives you pause, that pause is the answer. Most retailers who asked me about building ended up buying with a small custom extension, and the ones who built anyway feature in the common mistakes article, where I discuss the pattern under its real name: scope creep with a developer contract attached. Before you decide, also read the readiness signals article, because the build conversation usually starts at exactly the moment a business should be planning a package selection instead.