Buy the Commodity, Build the Differentiator

The Decision in Front of You

Every company runs two kinds of software. One kind does work that every competent company does the same way: paying people, closing the books, sending email, tracking support tickets. The other kind does the work customers pay for: the pricing engine, the routing model, the product itself.

The decision is whether to treat these differently in budget and governance. Most organizations do not. They apply the same appetite for customization to payroll as to the product, and they fund both from one project pot.

The stakes are large because software projects already miss badly on average. A McKinsey study with the University of Oxford of more than 5,400 IT projects, published in 2012, found large projects ran 45% over budget and delivered 56% less value than predicted, and 17% went badly enough to threaten the company ². The data is old, and the pattern in this paper's recent cases suggests it still holds.

What's Happening

Customization is where ERP programs break

West Sussex County Council. The council approved £2.6 million in November 2019 to replace its SAP system with Oracle Fusion ⁴. By March 2026 the estimate stood at about £41 million: £14.07 million already spent plus £27.05 million approved to finish, roughly 15 times the original figure ⁴. The council ended its contract with its systems integrator in 2023, after finding no real prospect of a deliverable plan, and is selling buildings to pay for the work. HR and payroll for more than 20,000 users moved to October 2026 ⁴. Its auditor, EY, reported weaknesses in budgeting, governance and risk management ⁴. The lesson is about scale: a commodity back-office replacement became one of the largest capital commitments in the council's portfolio.

Zimmer Biomet. In September 2025 the medical device maker sued Deloitte Consulting for at least $172 million over an SAP S/4HANA program ⁵. The complaint alleges Deloitte promised delivery with minimal customization, then delivered an overly customized system with defects and functionality gaps after a July 2024 go-live, on $94 million in fees, followed by tens of millions of dollars in remediation and supply chain disruption ⁵. Deloitte calls the claim meritless and has moved to dismiss ⁶. The allegations are unproven. They are still instructive, because both sides of the dispute treat minimal customization as the standard a competent ERP program should meet.

Birmingham City Council is the best-known example, covered in depth elsewhere. One detail belongs here: the council planned to run Oracle out of the box, built customizations anyway, and a custom banking reconciliation failed, leaving it unable to produce auditable accounts. The forecast cost reached £144.4 million against an initial £19 million ³.

Upgrades turn old customizations into new bills

Packaged software changes on the vendor's schedule. SAP ends mainstream maintenance for Business Suite 7, which includes ECC 6.0, at the end of 2027, with extended maintenance to 2030 at a premium ⁷. As of September 2024, Gartner found only 37% of ECC customers had licensed S/4HANA ⁷. Every custom object a company added to ECC over twenty years now has to be found, judged, and rewritten or retired before that move. The companies with the most customization face the largest bill and the least room in the timeline.

The commodity is getting more expensive to rent

Buying has its own rising cost. Vertice, which tracks more than $75 billion of processed software spend, measured SaaS price inflation at a record 16.4% in June 2026 and a preliminary 14.3% in September 2026 ⁸. Gartner forecast software spending would grow 14.2% in 2025 to $1.25 trillion, and its analyst said much of that growth would only offset price increases on recurring contracts ⁹.

A $1 million annual SaaS contract rising 12% a year costs about $1.57 million in its fifth year and $6.35 million over five years, against $5 million at flat pricing (author's arithmetic). That cost is real, and the answer to it is a hard negotiation and a tested exit path. Rebuilding payroll in-house would trade a 12% price rise for the full cost of owning payroll code.

AI makes custom code cheaper to write, and the upkeep remains

The newest objection to buying is that AI coding assistants make building nearly free. The evidence so far is mixed and argues for caution.

METR ran a randomized trial in early 2025 with 16 experienced developers on 246 real tasks in mature codebases they knew well. With AI tools allowed, tasks took 19% longer, while the developers believed they had been about 20% faster ¹⁰. METR's February 2026 follow-up found point estimates of an 18% speedup for returning developers and 4% for new ones, with intervals that include a slowdown. METR itself called the data weak evidence, because many developers refused to work without AI ¹¹.

Google's DORA research reached a similar split at the organizational level. Its 2024 report associated rising AI adoption with an estimated 1.5% fall in delivery throughput and a 7.2% fall in delivery stability ¹⁴. Its 2025 report, built on nearly 5,000 respondents, found AI adoption now associated with higher throughput while still associated with lower stability ¹². GitClear's analysis of 211 million changed lines from 2020 to 2024 found copy-pasted lines rising from 8.3% to 12.3% and refactoring falling from 25% of changed lines to under 10% ¹³.

Read together, AI lowers the cost of producing a first version. It has not been shown to lower the cost of owning code for ten years, and some evidence points the other way. Every line an assistant writes inside a vendor's ERP is a line your team must carry through the next upgrade.

Why the Usual Approach Fails

The common mistake is letting the department that will use a system decide how much to change it. Finance wants the ledger to match last year's chart of accounts and approval chain. HR wants the old leave rules. Each request is reasonable and cheap on its own. The project team, measured on user acceptance, says yes.

The cost lands later and elsewhere. Custom code in a packaged product must be retested at every vendor release, rewritten at every major version, and understood by someone after the original developer leaves. It rarely has an owner or a budget line after go-live. The incentive stays the same from project to project: the people who ask for customization never see its maintenance bill.

There is a second mistake in the other direction. Companies buy a package for something that does set them apart, then bend their best process to fit the vendor's average one. A distributor whose edge is same-day allocation across forty sites gains nothing from a generic allocation module. That company should build the allocation engine and buy the ledger.

Both mistakes come from skipping the classification step. Without it, build-or-buy gets decided project by project, by whoever is in the room.

The Framework: The Customer Test

Two established frameworks make the same split. Simon Wardley's mapping places every component on an evolution axis from genesis through custom-built and product to commodity, and recommends differentiating on the evolving components while sourcing the commodity ones externally ¹. Gartner's pace-layered model sorts applications into systems of record, differentiation and innovation, each with its own rate of change and governance ¹⁵. An executive team can apply the same idea with one question asked of every system.

flowchart TB
    A[Would a customer choose us<br/>or pay more because of<br/>how we do this?] -->|No| B[Commodity<br/>buy SaaS or package]
    A -->|Yes| C[Differentiator<br/>build or extend]
    B --> D[Adopt vendor process<br/>extensions outside the core<br/>no core code changes]
    C --> E[Own the code<br/>fund a standing team<br/>measure the advantage]

Commodity systems get bought and configured. The default is the vendor's process. A change to the vendor's core code needs sign-off from the CFO, because it creates a permanent liability. Needs the package cannot meet go into separate, small extensions that talk to it through published interfaces, so an upgrade does not break them. Contracts include data export and an exit plan, given the pricing trend above.

Differentiating systems get built or deeply extended, owned by a standing team, and measured against the advantage they are supposed to create: margin, conversion, delivery time. This is where AI coding tools belong, because the code is yours to keep and improve anyway, and the team that owns it will review what the tools write.

Most portfolios sort fast. In the author's experience, a mid-size company finds that only a handful of its systems pass the Customer Test.

What customization costs over five years

The model leaves out the larger risk in the recent cases, a failed go-live that halts billing, payroll or shipping.

Costs, Risks, and Tradeoffs

How to Act

Questions to Ask Your Team

1. Which of our systems would a customer notice if we ran them exactly like our competitors do?
2. How many custom objects sit inside our ERP, HR and CRM systems, and who owns each one?
3. What did our last major upgrade cost, and how much of that was retesting customizations?
4. Which vendor support deadlines fall in the next three years, and how much custom code stands in the way?
5. Where are we spending engineering time on a commodity system that a configuration change or an off-the-shelf add-on would cover?
6. For each system we built ourselves, what advantage does it create, and how do we measure it?
7. If our largest SaaS vendor raised its price 15% at renewal, what would we do?
8. Who reviews and owns code written with AI assistants after the person who prompted it moves on?

Closing

Software that does the same job at every company should cost as little to own as possible, which means buying it, adopting its process and keeping your code out of its core. Engineering money, and the new speed from AI tools, belongs in the few systems that make customers choose you. Classify the portfolio once, put a CFO signature on every core customization, and review the custom code count every quarter.