A home goods brand at $60M spent fourteen months on an ERP implementation and went live with 43 customizations. Each one had a reason. Four years later they wanted to add a marketplace channel, a project the vendor quoted at six weeks. It took nine months.

Not because the marketplace integration was hard. Because 31 of the 43 customizations touched the order object, and every one had to be regression tested against a schema change. The work was not building the new thing. The work was proving the old things still stood up.

That is the shape of the problem. No single customization is the mistake. The mistake is that each one is approved on its own merits, against its own business case, while the cost it creates lands on every future project instead of on the one that authorized it.

Configuration versus customization

The distinction gets blurred in vendor conversations, usually deliberately, and it is the single most useful line to hold.

Configuration is using capability the platform ships. Setting up a new warehouse, defining an approval threshold, adding a custom field, building a workflow from supported building blocks. It survives upgrades. The vendor tests it. Someone who was not in the room can understand it from the admin screen.

Customization is code that would not exist if you had not written it. A modified object, a bespoke integration, a screen the vendor has never seen, a trigger firing logic nobody outside your building has read. It does not survive upgrades unattended. Nobody tests it but you.

The reason this matters is that the two have completely different cost curves. Configuration costs what it costs, once. Customization costs what it costs, once, and then again at every upgrade, every adjacent project, and every staff change, forever.

	Configuration	Customization
Upgrade behaviour	Carried forward, vendor-tested	Re-validated by you, every time
Who can change it	An operator, in an admin screen	A developer who knows the codebase
Knowledge risk	Documented by the vendor	Lives with whoever wrote it
Cost profile	One-time	One-time plus indefinite carry
Reversibility	Toggle	Project

What the carry actually costs

The build quote is the number everyone sees. It is usually the smaller half.

Single moderate ERP customization, five-year view:

  Initial build (spec, dev, test, deploy)     = $28,000

  Carry costs:
   Regression testing at 2 upgrades/yr
     6 hrs × 10 upgrades × $140/hr            = $8,400
   Breakage and remediation
     (industry-typical: 1 in 4 customizations
      breaks per major version)                = $11,000
   Documentation and handover across
     one staff turnover event                  = $4,500
   Drag on 3 adjacent projects
     (2 weeks each of test/rework)             = $33,600
  ─────────────────────────────────────────────────
  Five-year total                              = $85,500

  Build cost as share of true cost:              33%

The adjacent-project drag is the line that surprises people, and it is the one the fourteen-month brand ran into. It scales with how central the customized object is. A customization on a reporting view drags almost nothing. A customization on the order object drags every project that touches orders, which over five years is most of them.

That gives you a cheap prioritisation rule: the cost of a customization is roughly proportional to how central the object it touches is. Same build quote, wildly different carry.

Why it happens anyway

Nobody sets out to accumulate 43 customizations. Four forces produce them.

The gap is real and the deadline is now. The platform does not do the thing, the business needs it, and a workaround exists. Refusing is not free either.

The implementation partner is paid to build. Not maliciously — but the party recommending the customization is usually the party billing for it, and “you do not need that” is not a sentence their incentives favour.

Process gets encoded before it gets examined. The single largest source of unnecessary customization is replicating a workflow because it is the workflow, without asking whether it is a real requirement or an artifact of the last system. A surprising share of “we need this” traces to a constraint that stopped existing two systems ago.

Nobody owns the total. Each request has a sponsor. The accumulated carry has none.

The test to apply before the next one

Five questions, asked in order, before any customization is approved. Most requests die on question two or three, which is the point.

1. Is this a requirement or a habit? Would a competent operator arriving fresh design the process this way, or are we encoding how the last system made us work? Ask what breaks if we simply do it the platform’s way. Sometimes the answer is real. Often it is discomfort.

2. What does it touch? Name the objects. If the answer includes orders, inventory, or the customer record, the carry cost is high and the bar should be correspondingly high. Peripheral objects are cheap to customize and usually fine.

3. Who maintains it after the person who built it leaves? If there is no answer, the answer is nobody, and you have created an artifact that will be feared rather than maintained. Undocumented customizations do not get removed; they get routed around, which is worse.

4. What is the five-year number, not the build quote? Build plus upgrade testing plus expected breakage plus adjacent drag. If the sponsor will not accept the five-year figure against their business case, the business case was never strong enough.

5. What is the exit? Under what conditions would we remove this, and what would that cost? A customization with no exit condition is permanent by default, and permanent-by-default is how you get to 43.

When a customization is the right call

The five questions are a filter, not a prohibition. Some customizations are correct and refusing them is its own kind of damage. Three patterns usually justify the carry.

It encodes a genuine competitive difference. If the way you allocate constrained inventory across wholesale accounts is a real edge, encoding it is defensible. The test is whether a competitor copying your process would gain something. Most operational processes fail that test; a few pass it decisively.

The alternative is worse and permanent. Manual work that scales linearly with volume is a customization too, just paid in salary. A build that removes forty hours a month of manual reconciliation clears its carry cost quickly, and the comparison should be against the manual cost rather than against zero.

It is peripheral and self-contained. A custom report, a bespoke export for one finance process, an integration to a niche tool — these touch nothing central, drag no future projects, and can be deleted without archaeology. These are cheap and the bar should be low.

What none of those describe is the common case: a modification to core order or inventory behaviour, requested because a process has always worked that way, sponsored by someone who will have moved on before the third upgrade.

Unwinding what you already have

Most brands reading this are not at the selection stage. They have thirty of these and a project that keeps slipping.

The instinct is a cleanup project. That rarely gets funded, because removing a customization has no business sponsor — it delivers no new capability and carries real regression risk. Cleanup projects that depend on someone volunteering budget to make nothing visibly happen do not survive planning.

What works better is opportunistic removal attached to work that is already funded. When a project has to touch an object anyway, the incremental cost of removing a dead customization on that object is small, and the project has a sponsor.

To make that possible you need the inventory first:

Field	Why it matters
Objects touched	Predicts drag on future projects
Original sponsor and reason	Tells you whether the reason still exists
Current maintainer	Blank means nobody, which is the risk flag
Last modified	Untouched for years often means unused
Usage signal	The decisive one, and the one people skip

That last row is where the wins are. A meaningful share of customizations in any mature system are no longer used by anyone. The screen exists, the trigger fires, the report generates, and nobody has opened it in two years. Instrumenting usage before assuming a customization is load-bearing turns a scary removal into an obvious one.

What to ask at selection

If you are choosing a platform now, the customization conversation should happen before contract, not during implementation, and the useful questions are narrower than most RFPs ask.

Rather than “can the system do X”, which always gets a yes, ask whether X is configuration or code, and who tests it at upgrade. That single reframing separates capability from capability-shaped services revenue.

Then ask for the specifics on the things you know you need. For a brand selling through retail, the list is predictable: retail EDI onboarding for a new trading partner, channel-specific packaging and labelling, multi-location inventory allocation, order routing rules, and customer-specific pricing. For each, the answer is either a setting, a supported extension point, or a build — and a platform that answers “build” to three or more of those is a platform whose carry cost you are underestimating badly.

Ask what a typical customer’s customization count looks like after three years. Vendors who track it will tell you. Vendors who do not know are telling you something too.

The strategic version of the argument

Beyond any individual decision, the accumulation has a directional cost that shows up as slowness.

A heavily customized platform gets progressively harder to change, which means the business gets progressively slower to respond. New channel, new 3PL, new retail partner, an acquisition — each becomes a project rather than a configuration. The brands that move fastest are usually not the ones with the most capable system. They are the ones whose system they can still change.

That is the case for choosing platforms where the things you need are configuration rather than code. Native retail EDI, multi-location inventory, channel-specific packaging rules and order routing are all things brands routinely customize into an ERP at significant carry cost, and all things that should be settings.

Endless Commerce is built so the common cases are configuration: EndlessEDI for retail trading partners, multi-channel order routing, and inventory across locations are platform capability rather than bespoke code, so adding a channel or a retail partner is a change you make rather than a project you scope. That does not eliminate the customization question, but it moves the line a long way, and the line is where the carry cost lives.

If you are already deep in, the useful first move is an inventory rather than a purge. List every customization, tag each with the objects it touches and whether anyone alive maintains it, and sort by centrality. The ones on core objects with no maintainer are where your next project is going to lose its schedule, and knowing that before the project starts is worth more than the removal itself.