Build versus buy in 2026: what changed, and what absolutely did not

For about fifteen years the answer to "should we build this?" was almost always no, and that was correct advice.

Building meant a long project, a team you had to hire, a maintenance obligation forever, and a real chance of producing something worse than the product you could have licensed on Tuesday. Buying meant a subscription and someone else's problem. Anyone recommending "build" needed an unusually good reason.

That advice is now wrong for a specific and growing category of software, and it remains completely right for another. Telling those apart is most of the value in this decision, and it is not where most of the discussion is happening.

What actually changed

Four things moved at once, which is why the conclusion moved rather than just wobbling.

The cost of validating a build collapsed. This matters more than the cost of building. The historic risk was not that construction was expensive. It was that you found out eighteen months in whether the thing was right. When a working version exists in days, the expensive failure mode mostly disappears.

Per-seat pricing started breaking. Pure per-seat models fell from around 21% to 15% of the market in twelve months. That is not a pricing fashion; it is what happens when the work is done by agents rather than by people occupying seats. A model that charged for headcount stops describing the value being delivered.

Integration stopped being the largest line item. We wrote about this separately in the integration tax is falling, and it is the quiet input into every build case, because the reason bespoke software used to be unaffordable was rarely the software.

Regulatory pressure started favouring control. In regulated industries, being able to say where a decision was made, on what data, under whose accountability, is now a procurement requirement rather than a nice-to-have. That is easier to guarantee inside your own boundary.

Klarna replacing its licensed CRM with an internally built system is the headline example, and Gartner's projection that 35% of point-product SaaS tools will be displaced by agents before 2030 is the projected shape of it.

What absolutely did not change

Here is the part that gets skipped, and it is the part that decides whether your project succeeds.

Building is not the expensive half. Operating is. The build was never the main cost, which is precisely why making the build cheaper changes less than the excitement suggests. Someone has to patch it, monitor it, fix it at 2am, and still understand it in three years. Cheap construction plus no operating capacity produces an asset that quietly becomes a liability, usually around month nine.

Nobody rebuilds a system of record on a whim. Your general ledger, your core policy system, your student information system. These are slow, deep, boring and enormously expensive to get wrong, and their value is in being unexciting for a decade. The disruption is real at the edges and much smaller at the centre.

You still cannot build your way out of a definitions problem. If two departments disagree about what a field means, building software will produce a confident, consistent, disputed answer faster. We say this in almost every engagement and it lands about half the time.

Compliance obligations do not care who wrote it. Buying software transfers some risk to a vendor. Building it keeps all of it. For some organizations that is the point; for others it is an obligation they have not costed.

The decision, in the form we actually use

Not a matrix. Four questions, in order, and the first "no" is your answer.

1. Is this how you are different from your competitors? If the process is genuinely yours, the thing you do better than the firms you compete with, buying means adopting somebody else's version and becoming slightly more like them. Build. If it is payroll, buy it, and do not romanticise it.

2. Does an available product fit without bending your operation? The honest test is not the feature list. It is: how many of your real cases require a workaround? A product that covers 85% and needs a spreadsheet for the rest has not replaced a spreadsheet. It has added a subscription to one.

3. Can you operate it after it exists? Not build it. Operate it. Is there a name against it, a budget for it next year, and someone who answers when it breaks? If not, buy, or build with a partner who stays. This is the question that fails the most projects and gets asked the least.

4. Does being wrong here have consequences you have to answer for? If a regulator, a carrier or a court may eventually ask how a decision was made, you need control of the reasoning and the record. That pushes toward build, or toward a vendor who will contractually give you both.

Where we say "neither"

The recommendation clients least expect from a firm that builds software is that they should not commission any.

It happens often enough that it is one of our stated commitments, and the situations repeat:

• The process is broken, not the software. Automating an approval chain with four unnecessary steps produces a fast, expensive version of an unnecessary approval chain.
• The real problem is one integration. Sometimes an entire proposed platform exists to move data between two systems that could simply be connected.
• The system is fine and the data is a mess. New software on top of duplicated records inherits the duplicates and adds a migration.
• Nobody owns the outcome. If no executive is accountable for the result, the project will be delivered and not adopted. We would rather say so.

Saying this costs us a project and earns the next three, which is not altruism. It is the only version of this business that compounds.

The bottom line

Build versus buy is no longer a question with a default answer, and that is genuinely new. The collapse in build cost is real, per-seat software is under real pressure, and a category of tools that was safe to license for a decade is not safe any more.

But the reason build projects fail did not change. They fail because nobody operates the result, because the definitions were never agreed, or because the problem was never software. All three were true in 2015 and all three are true now.

The cheap part got cheaper. The hard part is where it always was.

If you want that argued honestly against your actual situation rather than against a market trend, that is what the first conversation is for, and what replacing a system really costs sets out the bill before anyone commits to either path.