Build, buy or integrate? A decision model for CIOs

Few technology decisions are as consequential, or as often rushed, as the choice between building software, buying it, or integrating what is already in place. The decision usually starts as a technical question. In practice, it shapes budgets, vendor relationships, team structures and how much room the organisation has to change course later.

In larger organisations, the question is rarely a clean choice between two options. Most landscapes already contain packaged platforms, custom applications and a web of integrations between them. The real question is where a new capability should live, and who will own it over its lifetime.

This article sets out the decision model we use to structure that conversation. It does not produce an automatic answer. It makes the trade-offs explicit, so that the decision can be explained, challenged and revisited.

Three options, not two

Buy means adopting a packaged product or SaaS platform and configuring it within the limits the vendor provides. You gain speed and a supplier who maintains the product. You accept the vendor's roadmap, data model and commercial terms.

Build means designing and engineering a solution that fits your processes. You gain control and fit. You also take on the long-term responsibility for maintenance, security, operations and the people who can do that work.

Integrate is the option that is often overlooked. It means extending and connecting systems you already have, or combining a packaged product with a thin custom layer, so that the capability emerges from how systems work together. In many enterprise landscapes, the value sits less in any single application and more in the flow of data and work between them.

Six lenses for the decision

We look at every build, buy or integrate decision through six lenses. Each one asks a question that leadership, not only IT, should be able to answer.

1. Differentiation: does this capability set you apart?

Start with the strategic question. Is this capability part of how your organisation competes, serves its customers or fulfils its mission? Or is it something every organisation needs to do well, but nobody chooses you for?

Commodity capabilities, such as standard finance, HR or collaboration functions, rarely justify custom development. Differentiating capabilities are where generic software tends to force you towards the same processes as everyone else.

2. Process fit: how far would you have to bend?

Every packaged product carries assumptions about how work should be done. Sometimes adopting those assumptions is an improvement. Sometimes it means workarounds, parallel spreadsheets and manual steps that quietly become permanent.

The useful question is not "does the product have the feature?" but "how much of our process would we have to change, and are we willing to?" If the honest answer is "very little", buying is usually the stronger option.

3. Integration landscape: where does the data need to flow?

No new system operates in isolation. Map the systems it must exchange data with, the direction and frequency of that exchange, and who is the source of truth for each data element.

If most of the complexity lies in connecting existing systems, the right answer may be integration rather than a new application. If a packaged product offers limited or closed interfaces, factor the cost and risk of working around them into the decision from the start.

4. Total cost of ownership: what does it cost over its lifetime?

The price on day one is the least reliable indicator. A fair comparison covers the full lifetime of the solution: licences or development, implementation, integration, training, internal time spent adapting processes, maintenance, hosting, upgrades and eventually replacement or exit.

We explored this in more detail in The Real Cost of Custom Software vs. Off-the-Shelf Solutions. For enterprise decisions, we recommend comparing options over the same multi-year horizon and making the assumptions behind each estimate visible, so they can be tested.

5. Control, risk and compliance: what are you dependent on?

Consider who controls the roadmap, the data and the hosting location. Ask how easily you could move away if the vendor changes pricing, direction or ownership. Check how each option supports your security requirements and regulatory obligations, including data protection and, where AI is involved, emerging AI regulation.

Lock-in is not automatically bad. It is a risk to be priced and managed consciously, not discovered later.

6. Capacity to own: who keeps it running?

Building software creates an ongoing responsibility. Someone must maintain it, secure it, monitor it and improve it, long after the project team has moved on. Buying shifts much of that responsibility to a vendor, but you still need people who manage the configuration, the contract and the integrations.

If no team is ready to own a custom solution for its full lifecycle, that is a strong argument against building, however attractive the design looks.

Putting the lenses together

Once the six lenses have been discussed, a pattern usually emerges:

Hybrid answers are common and often sensible. A packaged platform for the standard core, a well-designed integration layer, and a small custom component for what is genuinely distinctive can combine speed with control.

Five steps to a defensible decision

1. Define the outcome. Describe the business result that needs to change and how you will measure it, before discussing solutions.
2. Map processes and systems. Make the current process, the systems involved and the data flows visible.
3. Score the six lenses together. Involve business owners, architecture, security and operations, not only IT.
4. Compare options on the same horizon. Use lifetime cost, explicit assumptions and named risks for each option.
5. Record the decision and its triggers. Write down why you chose this direction and which changes, such as new regulation, scale or vendor direction, would justify revisiting it.

A decision recorded this way is easier to defend to a board, easier to hand over to a new team, and easier to change when circumstances shift.

How we approach it at Emplex

As an end-to-end business and technology consultancy, we work on both sides of this decision: the strategic choice and the delivery that follows. In our Strategy & Enterprise Architecture work, we assess processes and systems, define the architecture and build a roadmap around priorities, constraints and risk. When the decision leads to a build or an integration, we take it from design through to production and ongoing operations.

Our aim is not to steer every decision towards custom software. It is to help leadership teams make a choice they can explain, own and sustain.

Facing a build, buy or integrate decision? Tell us about the challenge, the systems involved and the outcome you need.