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 customization. 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

[Placeholder section. Sketch the history: bespoke systems in the 1970s and 1980s, the arrival of packaged ERP in the 1990s, the argument that standardizing on a vendor's process was cheaper and safer than building your own, and the consulting industry that grew up around making those packages fit.]

[Placeholder. The key point to land: the package was never the product. The product was the implementation, and the license was the entry ticket to it.]

What "configuration" actually means

[Placeholder. Walk through the vocabulary and what each term hides.]

• 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.

Why the gap never closes

[Placeholder. The structural argument: a package is designed for the average of its market, and no company is the average. Every gap is either absorbed by people doing manual work, or closed by paid development. Both are ongoing costs, and only one of them shows up in the software budget.]

[Placeholder. Then the compounding problem: every customization makes the next upgrade harder, so the system slowly freezes while the business keeps moving.]

What changes when you admit it is a build

[Placeholder. If the work is a development project either way, the questions become simple ones. Who owns the result? What is it modeled on, a vendor's assumptions or how your business actually runs? What happens when the business changes? And what are you paying for: hours, seats, or the outcome?]

[Placeholder. Close on the thinkbridge position and link to the method, without turning the piece into a pitch.]

This is a draft. Replace the placeholder sections with the final piece, confirm the Gartner figures against the source before publishing, and add the author, date and reading time.