When Off-the-Shelf Software Stops Being Cheaper

Off-the-shelf software is cheaper than building custom software, right up until it isn't — and most organisations cross that line without noticing, because the costs that push them across it rarely appear on the product's price list. This is a companion piece to our build vs buy framework.

Why the comparison looks simple and isn't

A commercial product's licence fee is a known, upfront, easily comparable number. A custom build's cost requires estimation, and estimation carries real risk, as we cover in what custom software actually costs. This asymmetry — one number is known, one is estimated — biases the comparison toward "buy" even in cases where buy is not actually cheaper over the relevant time horizon, because the visible number is being compared against a number that feels riskier simply because it required more work to produce.

The costs that accumulate on the "buy" side

Configuration and customisation that never stops. A product configured to fit your process at implementation continues to need configuration as your process evolves — and every configuration change carries the risk, covered in our build vs buy piece, that heavy customisation of someone else's platform produces the worst of both worlds: licence fees, vendor lock-in, and a codebase you still have to maintain. We go deeper into this specific failure mode in a companion piece.

Workarounds that substitute for missing functionality. When a product cannot do something your process needs, the common response is a manual workaround — a spreadsheet, an email chain, a person doing the reconciliation the software should do. Workarounds are invisible costs: nobody budgets for them, they consume real time indefinitely, and they tend to multiply rather than disappear.

Integration cost with every other tool in the stack. A product that does not integrate cleanly with your other systems requires either custom integration work or continued manual data transfer between systems. This connects directly to the point covered in our companion piece on integration debt — every tool added to a stack has to talk to the others, and the connections need maintaining as both ends change.

Licence cost that scales with usage in ways a custom system would not. Per-seat or per-transaction pricing that seemed reasonable at initial scale can become the dominant cost line as the organisation grows, in a way a custom-built system's marginal cost of an additional user typically does not.

Switching cost that grows every year you stay. The UK Competition and Markets Authority found that in cloud services, less than 1% of customers switch provider each year, with technical and commercial barriers that "lock customers into their initial choice of provider." (CMA, July 2025) The longer a heavily customised commercial product is in place, the more expensive it becomes to leave — a cost that belongs in any honest comparison but almost never appears in one.

A test for whether you have crossed the line

Count the workarounds, honestly, across the whole team. If multiple people maintain manual processes specifically because the product doesn't do something, add up the time cost across all of them — it is usually larger than anyone individually realises, because each person only sees their own workaround.

Total the customisation spend over the product's lifetime, not just at implementation. If customisation and configuration costs have recurred every year rather than being a one-time implementation expense, that recurring cost is a real, ongoing number that belongs in the comparison against a custom build's total cost of ownership.

Ask what a comparable custom system would cost to maintain, not just to build. The comparison that matters is total cost of ownership on both sides, covered in our dedicated TCO piece, not initial licence fee against initial build estimate.

What this doesn't mean

This is not an argument that off-the-shelf software is usually the wrong choice — for most functional, non-differentiating needs, it remains the right one, as covered in our build vs buy framework. It is an argument that the comparison needs revisiting periodically, because a decision that was correct at initial purchase can become incorrect years later as customisation, workarounds and switching costs accumulate, and nobody re-runs the comparison unless something forces the question.

What we do

When we review a client's existing technology stack, we look specifically for accumulated workaround and customisation cost that has quietly moved a product past the point where it remains the cheaper option. If you suspect a commercial product has become more expensive than it looks, that is a conversation we are glad to have.

Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions.