Build or Buy in 2026: A Decision Framework for the Software That Runs Your Business

The build or buy question used to have a comfortable default. Buy, unless the thing in question was your actual product. That advice served a decade well, because building was expensive, vendors were consolidating around good general solutions, and the integration surface of a typical business was small enough that another subscription did not meaningfully complicate anything.

Three things have changed and the default no longer holds cleanly. Building is materially cheaper than it was, because AI assisted engineering has compressed the cost of the routine seventy percent of any codebase. Buying is more crowded, because every category now contains forty vendors and choosing badly is its own expensive mistake. And the accumulated integration surface at a typical mid sized company has grown to a point where adding the fortieth tool has a real ongoing cost that never appears on the invoice for it.

So the question needs a better framework than a default. This is the one we use, including the parts that regularly conclude a client should not build, which is a conversation we have more often than the reader might expect from a firm whose business is custom software engineering.

Start with the differentiation test, and be honest

The first question is whether the process in question is a source of advantage or a cost of doing business. Payroll is a cost of doing business for essentially everyone. Nobody wins on payroll. The way a specialist logistics firm sequences multi leg deliveries against changing constraints might be exactly how it wins, and that firm running the same routing software as its competitors has handed away the thing it was best at.

The test is harder than it sounds because almost every organisation believes more of its processes are distinctive than actually are. We ask two follow up questions. First, could a competent competitor copy this process by watching you for a month? If yes, it is not a differentiator, it is a habit. Second, if you adopted the industry standard way of doing this, would a customer notice? If not, you are protecting a preference rather than an advantage.

Where the answer is genuinely that the process is distinctive, buying is the expensive option even when it looks cheap, because you will spend the next four years paying a vendor to gradually approximate what you already knew how to do, and never quite getting there.

Total cost of ownership, calculated properly on both sides

Most build versus buy analyses compare a build estimate against a subscription price, which is not a comparison at all. Both sides have costs the invoice does not show, and they are large enough to reverse the conclusion.

What buying actually costs over five years

• Licence fees, escalating. Assume increases at renewal, and assume your seat count grows with the business rather than staying flat.
• Implementation and configuration, which for anything operationally significant is routinely one to three times the first year licence.
• Integration engineering, both initial and ongoing, because every vendor API changes and every change is your problem.
• Customisation that hardens into a dependency. The consultant who built your workflow extensions is now load bearing infrastructure.
• The process changes you make to fit the tool, which have a real cost in efficiency and in staff patience.
• Data extraction at the end. Ask, during procurement, exactly how you would leave. The quality of that answer is informative.

What building actually costs over five years

• Initial delivery, which is the number everyone focuses on and rarely the largest one.
• Maintenance at roughly fifteen to twenty five percent of build cost per year, covering dependency updates, security patching, and small changes.
• Hosting and operations, which for most business software is a modest but permanent line.
• Key person risk, unless the handover was done properly with documentation and more than one person who understands the system.
• The opportunity cost of engineering attention, which is the real constraint for most organisations rather than money.

Run both columns over five years rather than one. The pattern that emerges repeatedly is that buying wins clearly in year one, the lines converge somewhere around year two or three, and build wins from there onward if the system is still needed. Which means the honest question is not which is cheaper, but how confident you are that you will still be doing this in three years.

The customisation trap

There is a failure mode that produces the worst outcome available, and it is extremely common. An organisation buys a platform, discovers it does not quite fit, and customises. Then customises further. Three years later it is running a heavily modified system that costs licence fees, cannot be upgraded without breaking the modifications, requires specialist consultants who understand that specific vendor's extension model, and still does not do what the business needs.

This is worse than either pure option. You have the cost structure of buying and the maintenance burden of building, with none of the flexibility of the latter. It happens because each individual customisation is defensible in isolation, and nobody stops to add them up.

“The moment you are paying a specialist to make a platform behave unlike itself, you have already chosen to build. You have simply chosen to build on the most expensive possible foundation.”

The practical guard is a rule agreed before procurement. Decide, in advance, how much configuration you will accept before you conclude the platform is wrong. Something in the region of twenty percent of workflows requiring workarounds is a reasonable threshold. Beyond that, revisit the decision honestly rather than continuing because of what has already been spent.

What AI assisted engineering actually changed

There is a great deal of noise about this, so it is worth being specific. AI assistance has substantially reduced the cost of the routine parts of software: forms, endpoints, data access, tests, migrations, admin interfaces, and the general connective tissue that makes up most of any codebase by volume. In our own delivery, that portion of work has genuinely compressed, and the effect on a project of moderate size is real.

What it has not changed is the hard part. Understanding a domain deeply enough to model it correctly is unchanged. Designing an architecture that will still be workable in four years is unchanged. Knowing which of five plausible approaches will survive contact with production is unchanged. Debugging a subtle failure in a distributed system is, if anything, harder now, because more code exists that nobody wrote from scratch.

The consequence for build versus buy is a shift rather than a revolution. Projects that were marginal at the old cost are now clearly viable. Projects that were unthinkably large are now merely large. And the fixed cost of a competent team that understands your domain has become a bigger share of the total, which slightly favours doing more with one good team rather than spreading across many vendors.

The other consequence is a warning. Cheaper code makes it easier to build the wrong thing quickly. The discipline of deciding what should exist matters more now, not less, because the cost of skipping that step has gone down and the cost of the resulting mess has not.

Integration debt: the cost nobody assigns to anyone

Every tool you add creates connections to the tools already present. The tenth tool does not add a tenth of the complexity of the first nine, it adds considerably more, because the number of possible connections grows with the square of the count and the number that actually get built grows with it.

This cost is real, ongoing, and assigned to nobody. It surfaces as data that disagrees between systems, as a reporting layer nobody trusts, as an integration that breaks every time a vendor ships, and as the peculiar organisational tax of six tools each holding a partial view of the same customer. When a business tells us its biggest operational problem is that nothing talks to anything else, what it usually has is fourteen good individual buying decisions and no architecture.

This is frequently the strongest argument for consolidating into something built, and it is the reason custom ERP still makes sense for operations with genuinely distinctive processes. Not because a bespoke system is inherently better at any single function, but because one system with one data model removes an entire category of ongoing cost that no individual purchase decision ever accounted for.

A decision procedure you can actually run

1. 01Write down the process as it genuinely runs today, including the spreadsheets and the workarounds. If you cannot do this, neither option will succeed, because you do not yet know what you are automating.
2. 02Apply the differentiation test. Standard process, buy. Distinctive process, keep reading.
3. 03Survey the market properly. Three vendors, demonstrated against your actual workflows rather than their reference scenarios. Insist on seeing your awkward cases.
4. 04Score fit as a percentage of workflows supported without customisation. Above eighty percent, buy. Below sixty, build. In between, the answer depends on the next two steps.
5. 05Model five year total cost for both, using the lists above rather than the invoice.
6. 06Assess your own capacity honestly. Building requires someone internal who can own the result. If nobody can, buying is right even when the economics say otherwise.
7. 07Consider the hybrid. Buy the commodity layer, build the differentiated layer on top, integrate deliberately through a boundary you designed.

That seventh option deserves more attention than it gets. Very few organisations need to build everything, and very few can buy everything. The accounting package is bought. The customer portal that expresses how you actually work with clients is built. They meet at an integration boundary that somebody designed on purpose. That shape is the right answer far more often than either extreme, and it fails mainly when nobody owns the boundary.

Buying well is a skill, and most organisations are bad at it

If the analysis points to buying, the decision is not finished. It has merely changed shape. A bad purchase in a crowded category costs more than a modest build, and the failure modes are predictable enough to guard against.

Insist on demonstrations against your own workflows, not the vendor's. Every product demonstrates beautifully on the path its designers had in mind. Send three of your genuinely awkward cases in advance and ask to see them handled live. The response to that request tells you a great deal on its own, well before you see the software.

Talk to reference customers the vendor did not select. Two or three companies of similar size and shape, found independently, will tell you what the implementation actually cost and what broke in year two. Ask specifically about the gap between what was promised in the sales cycle and what was true after six months, because that gap is where most buyer regret lives.

Establish the exit path during procurement, while you still have leverage. What formats does your data come out in, how completely, and at what cost. A vendor that cannot answer this crisply is telling you something. The point is not that you expect to leave. It is that a switching cost you cannot quantify is a switching cost you will discover at the worst possible moment.

Finally, price the integration work before signing rather than after. A platform that is thirty percent cheaper and requires four bespoke integrations is not thirty percent cheaper. We have watched organisations select on licence cost and then spend more than the difference in the first year connecting the thing to systems they already had.

The hybrid pattern, in practice

The mixed approach is the one we implement most often, so it is worth describing concretely rather than as an abstraction. A distribution business we worked with kept its accounting package, kept a mature warehouse management system, and built the layer that sequences orders against stock, customer commitments, and carrier constraints, because that sequencing was the actual business. Three systems, one designed boundary, and the built portion was perhaps fifteen percent of what a full replacement would have cost.

What makes this work is treating the boundary as a deliberate piece of engineering rather than a set of point to point connections added as needed. One place owns the canonical customer record. One place owns stock truth. Data flows in a defined direction with a defined shape, and where two systems disagree there is a documented answer about which one wins. That discipline is unglamorous and it is the entire difference between a hybrid architecture and an integration swamp.

It also has a pleasant property: it defers decisions. You can build the differentiated layer now and replace a bought component in three years without touching it, because the boundary absorbs the change. Organisations that build everything or buy everything lose that optionality, and optionality is worth a great deal when you cannot see three years ahead.

The same logic applies to the parts of a system your customers actually touch. Back office functions can be commodity, while the portal, the onboarding flow, and the interface where clients experience your service are frequently where a bought solution is most visibly generic. That is often the right first candidate for building, and it is why we usually pair a build decision with proper digital product design rather than treating the interface as something to be assembled afterwards.

When we tell clients not to build

We turn down work for these reasons regularly, and it is worth stating them plainly, because a firm that never says no is not giving advice, it is taking orders.

• The process is genuinely standard and a mature vendor covers it well. Rebuilding accounting or payroll is a way to spend money reproducing something that already works.
• The requirement is not stable yet. Building against a process that will change fundamentally within a year is building the wrong thing carefully.
• Nobody internal will own it. Custom software without an owner degrades quietly and becomes the system everyone is afraid of within three years.
• The budget covers the build but not the maintenance. That is a slow motion failure with a two year fuse and we would rather not light it.
• The real problem is organisational. Software does not fix a process nobody agrees on. It encodes the disagreement and makes it permanent.

Three signals that the decision has already been made for you

Sometimes the analysis is a formality because the situation has already resolved it. Three signals in particular mean the answer is build, and recognising them early saves a procurement cycle.

The first is when the shadow system is the real system. If the platform of record is used for compliance while the actual work happens in a spreadsheet that one person maintains, you are already running custom software. It simply has no tests, no backups, no access control, and a single point of failure who takes holidays. Formalising that spreadsheet is usually the highest return software project available to a business, and it is almost never on the roadmap because nobody counts it as software.

The second is when licensing has outgrown the value. Per seat pricing set when you had forty people looks different at three hundred, particularly for a tool where most of those seats need read access to two screens. When the annual figure crosses the cost of owning something outright, the calculation has changed even though nothing about the software has.

The third is when your growth plan breaks the tool. A platform that works at your current volume, geography, or entity count but has a known ceiling you expect to hit within two years is a migration you have scheduled without admitting it. Migrating under pressure at the moment of growth is considerably worse than building deliberately beforehand, and the cost difference between those two paths is large.

The question behind the question

Underneath build versus buy sits a question about control. Buying trades control for speed and predictability, which is an excellent trade for things you do not need to control. Building trades speed for control, which is an excellent trade for things where control is the point.

Most bad outcomes come from making that trade unconsciously. A company buys a platform for a process that turns out to be central to how it competes, then spends years fighting the vendor's assumptions. Or it builds an expense tool because an engineer thought it would be quick, and maintains it forever for no strategic reason whatsoever.

Get the differentiation question right and the rest is arithmetic. Get it wrong and no amount of careful costing will save the decision. That is why we spend the first conversation on the process rather than on the technology, and why the most valuable thing we produce in some engagements is a recommendation not to engage us at all.