Build vs Buy: When to Build Custom Enterprise Software and When to Buy

Most build-versus-buy decisions are settled before anyone opens a spreadsheet. Someone already holds a preference, the analysis is assembled to support it, and the organisation lives with that choice for years. This is a framework for making the decision properly: work out where your advantage actually sits, model both paths over the same horizon, and be honest about how each one fails.

It is worth saying at the outset that we build custom software for a living, and the recommendation is still frequently to buy. A custom system nobody is funded to own is a liability that arrives quietly, about eighteen months after launch.

The question behind the question

Build versus buy is not really a question about software. It is a question about which parts of your operation make you different from everyone else in your market, and whether the workflow under discussion is one of them. The rule of thumb is easy to state: buy what makes you the same, build what makes you different. It is harder to apply, because most workflows sit somewhere in between and because every department believes its process is distinctive.

Three tests place a workflow more reliably than a requirements list.

The differentiation test. If a competing organisation licensed the same product tomorrow and configured it the same way, what would you lose? If the honest answer is nothing, you are looking at a commodity, however important it is. Important and differentiating are not the same thing. Payroll is important.

The change-rate test. How often does the underlying process change, and who decides when it does? A process that changes every quarter because of your own commercial decisions will grind against a vendor release cycle. A process that has not changed in five years because a regulator defines it will not.

The coupling test. How many systems does this workflow touch, and who owns the data model at the centre of it? Workflows that sit at the junction of several systems are where products fit worst, because each product wants to be the system of record.

When buying is the right answer

Buying wins more often than build-side enthusiasm suggests, and in these situations it wins decisively.

The category is mature and the process is effectively a standard. General ledger, payroll, identity, endpoint security, email, core HR. Thousands of organisations have already argued about these requirements and the argument is settled. Your version of the process is not special enough to fund forever.

Certification is part of the purchase. In several regulated categories what you are buying is not only functionality but an auditable implementation your assessors already recognise. Reproducing that internally means reproducing the evidence, the controls and the annual assessment alongside the software.

You cannot fund an owner for the life of the system. This is the most reliable predictor of a failed build we know of. Custom software needs a named person who decides what it does next, for as long as it runs. If you cannot name that person and protect their time in year three, buy.

The usage does not justify a maintained code base. A workflow that runs a few times a month for a small team rarely repays its dependency upgrades, security reviews and on-call, whatever the build estimate says.

Time-to-value dominates the economics. If the workflow is losing money now and a product covers most of it this quarter, buy it and revisit later. Buying is reversible more often than teams assume. A half-built internal platform is not.

If you came here hoping for permission to build and your situation matches three of the above, take the honest answer. Buy, and spend the engineering attention you just saved on something your customers can see.

When building is the right answer

The workflow is the product, or directly produces it. If customers pay you because of how this process works, handing its design to a vendor caps your ceiling at whatever that vendor's other clients also have.

Your data model is the asset and every product wants to bend it. When evaluations keep ending in a note that you would have to restructure how you represent customers, contracts or entitlements, the product is asking you to adopt someone else's view of your business.

You already pay more for integration and workaround than for the licence. This is a common late-stage signal. When annual spend on adapters, syncs, exports, reconciliation scripts and the people who supervise them exceeds the subscription, the product has stopped being the cheap option.

The process changes faster than any roadmap. If your competitive response time is measured in weeks and the vendor ships twice a year, you will either wait or build shadow systems around the product. Most organisations do both.

Residency, sovereignty or isolation requirements that no vendor will meet. Deployment constraints are a legitimate build reason and are increasingly the deciding factor in regulated and public-sector work.

The option most teams skip

The question is rarely all-or-nothing, and the strongest answer is usually composition: buy the substrate, build the edge. Identity, storage, data warehousing, payments, messaging and model hosting are commodity, so take them. Build the thin layer that encodes the judgement your organisation is actually paid for, and keep that layer small enough that one team can hold it in their heads.

Two anti-patterns sit either side of this. One is rebuilding commodity infrastructure because it looks like engineering. The other is buying a suite so wide that your differentiator ends up expressed as configuration inside someone else's abstraction, where you can neither change it nor extract it.

Modelling the cost honestly

You are not comparing a licence to a project. You are comparing two operating commitments over the same period, and three to five years is usually enough to expose the difference. Model the do-nothing baseline alongside them, because the manual process you run today also has a cost.

On the buy side the drivers that matter are implementation and configuration effort, data migration, integration work and the ongoing maintenance of those integrations, per-seat or per-usage growth as adoption spreads, tier changes, renewal escalation once the process is embedded and your leverage has gone, the administration and support staffing the product needs internally, training as your team turns over, and the cost of leaving, which includes extraction, retraining and a period of parallel running.

On the build side the drivers are discovery, delivery, the last mile that estimates always miss, infrastructure and run costs, on-call, security review and testing, dependency and framework upgrades, documentation, and the product ownership commitment for the life of the system. That last mile deserves naming explicitly: permissions, audit trails, administration screens, reporting, error states, bulk operations and historical data migration. Add the opportunity cost of the engineering attention consumed, which is real even when it never appears in a budget line.

Two lines are missed most often. On the buy side it is the integration tax, which grows as more of your estate connects to the product. On the build side it is the maintenance floor, the irreducible cost of keeping a system alive in a year when it gains no new features. Model year one and year four separately. The ranking frequently inverts between them, and whichever year you happen to look at is the answer you will convince yourself of.

How each path fails

Builds fail in recognisable ways: no named owner after launch; scope copied from a vendor's feature list rather than derived from the actual workflow; the interesting part built and the administrative part abandoned; one engineer holding the whole design; no plan for retiring the thing it replaced, so both run indefinitely; and treating go-live as the finish line rather than the start of the cost.

Purchases fail in equally recognisable ways: customisation deep enough that every upgrade becomes a project; configuration with no source of truth, so nobody can say why the system behaves as it does; data that is technically exportable but not usefully so; roadmap dependency, where your priority sits behind other customers; and the shadow spreadsheets that reappear within a year because the product does not fit the exception cases your business actually runs on.

A decision procedure you can run in a fortnight

Write the workflow down, including the exceptions. Not the idealised version. The exceptions are where products break and where builds overrun.

Sort requirements into three piles: standard, adaptable and distinctive. If the distinctive pile is small, you are buying. If it is large and sits at the centre rather than the edges, you are building.

Run a scripted evaluation, not a demonstration. Give shortlisted products your three hardest exception cases and your real data, and make the vendor's team work them in front of you. Demonstrations are designed to avoid exactly those cases.

Cost both paths over the same horizon using the drivers above, at year one and year four.

Apply elimination rules before scoring. No funded owner, do not build. Distinctive requirements dominate and the data model is yours, do not buy a suite. Residency constraints no vendor meets, build or self-host. Two or more products cover it and your team is already stretched, buy.

Write down the assumption that would change the decision and diarise a review for the point at which you would know. Most build-versus-buy regret comes not from choosing wrongly at the time but from never revisiting a choice after the conditions changed.

When not to bring in an external partner

If you have decided to build, the system is core to your product, and you can hire and keep the engineers, build it with your own team. External help earns its place for bounded scope, unfamiliar territory, a capacity spike against a fixed date, or an independent view of a project that has stopped moving.

It is the wrong instrument when the work is a permanent stream of small changes, when nobody internally can be freed to make decisions weekly, or when you cannot yet describe what finished looks like. And if the motivation for using a partner is that headcount is hard to approve while project spend is not, the cost comes back as coordination overhead and rework. That is an organisational problem, not a sourcing one.

What a good decision looks like

Buy when the process is a standard, when certification is part of what you need, or when you cannot fund ownership for the life of the system. Build when the workflow is your advantage, when it changes faster than any roadmap, when the data model must stay yours, or when deployment constraints leave no alternative. Compose when the honest answer is some of both, which it usually is.

Whichever you choose, name the owner before you start. That single decision predicts the outcome better than the build-versus-buy choice itself.

If you want a second opinion on where a specific workflow sits, see how we scope and run engagements or read about our approach to custom software.