Every off-the-shelf system is a custom development project in disguise.

Nobody sets out to build custom software. That is the whole promise of buying a package: somebody else has already done the hard part, and what is left is a configuration exercise. A few weeks of setup, some training, and your business is live on software that thousands of companies already trust.

Then the project starts. The fields do not match the way your team refers to a customer. The approval chain has four steps and the system supports two. The pricing rules that took your business fifteen years to work out cannot be expressed in the rules engine, so they move into a spreadsheet that sits alongside the system forever. None of this is called development. It is called configuration, or extension, or a low-code customisation. The bill arrives all the same.

The word changed. The work did not. You are still paying somebody to build software, only now you do not own what they build.

How the promise was made

In the 1970s and 1980s, a company that needed software had it written. Its own programmers, or a contracted firm, built the payroll, inventory and order systems around the way that company worked. The systems fit. They were also expensive to build, and they depended on the handful of people who understood them.

Packaged ERP arrived in the 1990s with a different offer. Buy the software once, adopt the vendor's process, and share the cost of development with every other customer. Standardising on a vendor's way of working was sold as cheaper and safer than building your own, and for many companies it sounded like the end of custom development.

It was the start of an industry. Systems integrators and consulting firms grew up around the packages, and their main business was making the software fit the companies that had bought it. On large projects the services bill often ran larger than the licence.

The licence was the entry ticket. What companies actually paid for, year after year, was the implementation.

What "configuration" actually means

Each stage of that work has its own name, and each name makes the work sound smaller than it is. Read the terms on any implementation proposal and translate them:

• Configuration. Development, done inside the vendor's tooling, by people who charge by the day.
• Extension. Development, done outside the vendor's tooling, that you will maintain but cannot fully control.
• Low-code and no-code. Development, done faster at the start and slower at every change after, by whoever is still around to understand it.
• Integration. Development, to make two systems agree on facts your business already knew.

The number behind this

Implementing an ERP typically costs another one to two times the license (ERPfocus, 2024). The licence is the smallest line on the page.

Why the gap never closes

A package is designed for the average company in its market, and no company is the average. The differences are usually where a business competes: how it prices, and how it handles the customers who do not fit the standard form.

Every difference gets closed in one of two ways. People absorb it with manual work, or the company pays for development to close it. Both cost money every year. Only the development shows up in the software budget. The manual work sits in headcount, in overtime and in the spreadsheet beside the system.

The development carries a second cost. Every customisation is code the vendor did not write and will not test. When the next major version ships, each one has to be checked, rewritten or dropped. Companies with heavy customisation start delaying upgrades, then skipping them. The system stays at the version that fit the business several years ago, while the business keeps changing.

What changes when you admit it is a build

If the work is a development project either way, ask the questions you would ask of any build. Who owns the result? Is it modelled on a vendor's assumptions or on how your business actually runs? What happens to it when the business changes? And what are you paying for: hours, seats or an outcome?

We built thinkbridge around those questions. We build custom-fit, AI-native systems that our clients own, modelled on how their business runs, using thinkOne, our methodology that pairs forward-deployed experts with an agentic engineering and delivery platform. Whoever you work with, ask the four questions before the next renewal or implementation proposal arrives.

All blogs