Build vs buy software: a decision framework for enterprises

Build versus buy is one of the oldest questions in enterprise technology, and it is usually framed wrongly. The real choice is rarely all-build or all-buy. It is which capabilities you own outright, which you rent, and how you join them together. Get that mix right and you spend your engineering budget where it actually changes the business.

Most large organisations run hundreds of software capabilities. Treating each one as a fresh build-or-buy decision is exhausting and beside the point. The useful work is sorting capabilities by how much they matter to your business, then matching each to the model that fits. This guide gives you a framework for doing that, with the trade-offs spelled out and the common traps named.

The real question is not build or buy

When a team frames a decision as build or buy, they tend to argue two extremes. One side wants control and a perfect fit, so they build. The other wants speed and a fixed cost, so they buy. Both are right about part of it and wrong about the whole, because almost no enterprise system is purely one or the other.

A better starting question is: how much does this capability differentiate us? Payroll does not win customers. A pricing engine that quotes faster than anyone else might. Once you separate the capabilities that set you apart from the ones that simply have to work, the build-or-buy answer falls out of that judgement rather than out of a preference for one model.

A decision matrix

For any given capability, run it through these factors. None of them decides on its own, but together they point clearly enough.

• Is it core and differentiating? If this capability is part of why customers choose you, lean towards build. If every competitor runs the same thing, lean towards buy.
• Does off-the-shelf fit 80 percent or more? A mature product that covers most of your requirements out of the box is hard to beat on cost and speed. Below that threshold, the gap you have to fill starts to erode the advantage of buying.
• Total cost of ownership. Look past the licence or the project quote to the five-year picture: hosting, support, per-seat fees, integration, configuration and the cost of change. Cheap to start is not the same as cheap to keep.
• Speed to value. Buying usually gets you live faster. Building takes longer but can move faster later when the capability needs to evolve in ways a vendor will not prioritise.
• Control. Building gives you full control of the roadmap, the data and the behaviour. Buying hands much of that to a vendor whose priorities are not yours.
• Lock-in. A bought product can become hard to leave once your processes and data wrap around it. Weigh how painful an exit would be before you commit.
• Integration cost. A product that does not talk to your other systems cleanly can cost more to wire in than it saves. Open APIs and clear data models matter as much as the feature list.

The composable default: buy commodity, build differentiation

For most enterprises the sensible default is a hybrid. Buy the commodity capabilities, build the parts that differentiate you, and integrate everything through APIs. This is not a compromise. It is the model that lets you concentrate scarce engineering effort on the small number of things that move the business while renting the rest.

A composable or MACH architecture is what makes the hybrid practical at scale. By treating each capability as an independent service with a clear API, you can pick the best product for a commodity need today and swap it later without rebuilding everything around it. Our guide to MACH architecture covers how microservices, API-first design, cloud-native delivery and headless front ends fit together. The same thinking underpins how we approach digital platforms: a foundation that lets teams compose bought and built capabilities rather than fighting a single monolith.

Two pieces of our own work show the trade-off handled well. For VisitBritain we used a MACH composable commerce approach, buying mature commerce capabilities and composing them rather than building a bespoke platform end to end. For Bauer Media we re-platformed onto a headless Next.js front end, separating the presentation layer from the underlying systems so each could be chosen and changed on its own merits. In both cases the value came from drawing the build-versus-buy line at the right place, not from picking a side.

When custom build wins

Build when the capability is genuinely core to how you compete and no product fits without heavy bending. The clearest signal is that a feature is the reason customers pick you. If you can only deliver it by twisting a bought product well past its design, you are paying build-level effort for a product you do not control.

Signals that point to build

• The capability is a source of competitive advantage, not a back-office necessity.
• Your requirements are specific enough that off-the-shelf options cover well under 80 percent.
• You need full control of data, behaviour and roadmap, and cannot accept a vendor setting the pace.
• You have the team or a delivery partner who can own the software across its life, not just ship version one.

When buy wins

Buy when the capability is a commodity that everyone in your sector runs in much the same way, and a mature product covers most of what you need. Payroll, email, payments, identity and standard content management are the obvious examples. Building these from scratch spends your best people on problems other companies have already solved well.

Signals that point to buy

• The capability is undifferentiated; doing it better than rivals would not win you a single customer.
• A proven product fits around 80 percent or more of your needs out of the box.
• Speed to value matters and you would rather be live in weeks than quarters.
• The product exposes clean APIs, so it integrates without becoming a closed island.

The trap of over-customising bought software

The most expensive outcome is not a clean build or a clean buy. It is buying a product and then customising it so heavily that you carry build-level cost and risk while still depending on a vendor. Every customisation has to be re-tested on every upgrade, and the deeper you go, the harder the product is to upgrade or replace at all.

If you find yourself bending a bought product well past its intended use, treat that as a signal. Either the capability is more core than you assumed and deserves a proper build, or your requirements need trimming back to what the product does well. Heavy customisation of off-the-shelf software is usually a decision that was made at the wrong line on the matrix. When the underlying problem is ageing systems that no longer fit, our view on modernising legacy systems covers how to break that dependency without a risky big-bang rewrite.

A decision checklist

For each significant capability, work through these in order.

1. Classify the capability. Is it core and differentiating, or commodity? Be honest; most capabilities are commodity.
2. Check the fit. For commodity capabilities, can a mature product cover roughly 80 percent or more without heavy customisation?
3. Model total cost of ownership over five years for both options, including integration, support and the cost of change.
4. Weigh speed, control and lock-in against that cost. Name what you are giving up in each option.
5. Assess integration. Will the bought option expose clean APIs, or will it become a closed island?
6. Confirm ownership. If you build, who owns the software after launch? If nobody, reconsider.
7. Default to composable. Buy the commodity, build the differentiation, integrate through APIs.

If you are weighing one of these decisions and want a partner who has handled the trade-off on real platforms, our digital product service puts cross-functional teams of product, design and engineering on the problem from day one.