The Real Question Behind Custom Software vs Off the Shelf

Williams JonesJuly 23, 2026

0 2 5 minutes read

Ask ten operations leaders whether to build custom software or buy an off-the-shelf product, and most will answer as if it’s a single decision for the whole business. It isn’t. The right answer changes depending on which specific function is being replaced, and treating it as one company-wide choice is how organisations end up with either an expensive bespoke system nobody needed, or an off-the-shelf platform straining against a process it was never built to support.

Key Takeaways

Around two-thirds of software projects fail because of the wrong build-versus-buy decision, not because of poor execution once the decision was made.
The UK government’s own service standard treats build-or-buy as a per-service decision based on available skills and resources, not a single organisational policy.
Off-the-shelf software has a genuinely lower total cost of ownership for standard, commodity functions, while custom software can be cheaper at scale for processes that are core to competitive advantage.
ISO/IEC 25010’s software quality model gives a useful shared vocabulary for comparing a custom build against a commercial product on functionality, reliability, and maintainability rather than price alone.
The decision should be made function by function, not as a single policy applied across an entire organisation.

Most of the genuine cost in this decision isn’t in the build or the licence fee. It’s in getting the decision wrong at the level of an individual business function and only discovering it once the system is already live.

Most Software Project Failures Trace Back to This Decision

Research cited in a June 2026 CIO piece on why CIOs should reopen the build-versus-buy question points to a striking figure: roughly two-thirds of software projects fail specifically because of the wrong build-or-buy choice, not because of poor project management once the decision was already made. That reframes the whole exercise. A skilled team executing well against the wrong decision still produces a failed project.

The Standish Group’s long-running research into IT project outcomes, based on tens of thousands of delivery projects across a thousand organisations, has consistently found that a large share of projects either fail outright or ship without meeting their original scope and budget. Build-versus-buy sits upstream of most of the factors that research examines: a project scoped around the wrong starting decision carries that risk through every later stage.

A team in a meeting room discussing a project on a whiteboard

The Question Isn’t Company-Wide, It’s Function by Function

The UK government’s Service Standard treats the build-or-buy decision as something to assess per service, weighing available staff skills, operational capacity, and whether a supplier can genuinely meet the specific need, rather than setting a blanket rule for every system a department runs. That’s a useful discipline for any organisation, not just government departments.

Treating build-versus-buy as one decision for the whole business is how a company ends up with expensive custom code protecting a function that was never actually a competitive advantage, sitting next to an off-the-shelf tool straining against the one process that genuinely was.

A finance system handling standard accounting doesn’t need custom development; the commodity function is well served by mature, tested products built by vendors who specialise in exactly that problem. A workflow that encodes the specific way a business actually serves its customers, the thing competitors can’t simply buy off a shelf, is a much stronger candidate for custom development, because an off-the-shelf tool will always be a compromise against a process the vendor built for a generic customer, not this one.

Total Cost of Ownership Looks Different Over Time

Sticker price rarely tells the real story. A 2019 academic case study on total cost of ownership in cloud migration shows how per-user subscription costs, additional modules, and integration fees can make an initially cheaper off-the-shelf product cost considerably more than expected once it scales to the organisation’s actual size. Custom software carries the opposite risk profile: a higher upfront cost, but no per-user licence fee compounding annually as the business grows.

Neither pattern is universally better. A fast-growing team evaluating a five-year horizon needs to model both trajectories, not just compare today’s quote against today’s estimated build cost. The right comparison is what each option costs at the user count and complexity the business expects to reach, not what it costs on day one.

A person reviewing financial spreadsheets and charts on a laptop

A monitor displaying lines of software code

A Shared Vocabulary Helps the Comparison

Part of why this decision goes wrong is that “better” gets used loosely, without specifying better at what. The ISO/IEC 25010 software quality model, revised in 2023, breaks software quality into distinct characteristics, including functional suitability, reliability, maintainability, and portability, giving teams a shared vocabulary for comparing a custom build against an off-the-shelf product on specific dimensions rather than a vague sense of which one feels more capable.

A custom system might score well on functional suitability, doing exactly what’s needed and nothing else, while scoring poorly on maintainability if the original development team moves on and nobody documented the codebase. An off-the-shelf product might score the reverse: strong maintainability because a vendor supports it long-term, but weaker functional suitability if it forces a business to adapt its process to the software rather than the other way round. Naming these trade-offs explicitly makes the decision defensible rather than a guess.

Where a business does land on custom development, the choice of development partner matters as much as the decision itself. A team that has actually delivered production software across genuinely different regulated sectors, rather than one template repeated with different branding, tends to ask sharper questions about which parts of a process are truly unique before writing any code. Arch’s portfolio of regulated-sector platforms is one example: a UK development company whose work spans healthcare, charity, and veterinary platforms, evidence of having made this build-versus-buy judgement call correctly across genuinely different contexts rather than defaulting to custom for everything.

Frequently Asked Questions

Is custom software always more expensive than off-the-shelf?

Not necessarily over the long term. Off-the-shelf products often have lower upfront costs but accumulate per-user licence fees that compound as an organisation grows, while custom software has a higher initial cost but no recurring per-user fee. Which is cheaper depends on the time horizon and expected scale.

How do I know if a business function needs custom software?

A function is a stronger candidate for custom development when it reflects something genuinely unique about how the business operates, rather than a standard process any competitor also needs solved. If an off-the-shelf product built for a generic customer would force the business to change how it actually works, that’s a signal custom development may be worth the cost.

Why do so many software projects fail even with skilled teams?

Research suggests a majority of failures trace back to the initial build-or-buy decision itself, not execution afterwards. A well-run project built on the wrong foundational choice still produces a system that doesn’t fit the actual need.

Should the same build-or-buy decision apply across a whole organisation?

No. The decision is best made function by function, based on whether that specific process is a commodity well served by existing products or something genuinely distinct to the business. A single blanket policy tends to produce mismatches in both directions.

What framework can help compare custom and off-the-shelf options fairly?

The ISO/IEC 25010 software quality model offers a structured way to compare options across specific characteristics, including functional suitability, reliability, and maintainability, rather than relying on a general impression of which option seems better.