Nobody Approved The Build

Thirty-two percent of organisations have decided against buying at least one software product or feature because it could be built in-house with agentic coding tools. Among high performers it is close to half, against 31 percent of everyone else. The numbers come from McKinsey's State of AI survey, published on 25 August 2026 ^[1] , with 1,719 respondents in 97 countries, fielded between 4 May and 8 June. Most of the coverage went to the flat EBIT line next to it. The more interesting finding is this one, because it describes a make-or-buy decision that moved without anyone deciding to move it.

Make-or-buy used to be one of the most heavily governed decisions in a company. Buying software means procurement, a security review, legal, a budget line, a named owner, a renewal date and an exit option. That is the mechanism by which an organisation decides, deliberately, what it is willing to carry for the next several years, and far more than bureaucracy for its own sake.

Building the same function with a coding agent passes through none of it. It happens inside a sprint and inside an existing team budget, often without anyone outside the team knowing. The saving lands in this year's numbers. The obligation lands in the three years after, usually on someone else's desk.

Let me be clear about where I stand, because this is easy to misread. The build itself is fine. For workflows that genuinely differentiate you in your market, building is often the right answer, and the fact that it is now feasible for teams who could never have done it before is real progress. The problem is that the decision lost its venue. In Renting Your AI Transformation I wrote about organisations renting their AI transformation from the labs. This is the same question asked from the other end, and it has the same shape: capability is arriving faster than the structure that is supposed to govern it.

The will was never the constraint

The Futurum Group surveyed 830 IT decision makers in January 2026 and published the results in June ^[2] . Build preference stood at 56.0 percent, essentially unchanged from 56.6 percent six months earlier. Companies have always wanted to build. What changed is that they now can, and not only in IT. In the same survey, 53.3 percent of organisations report that between 20 and 40 percent of their non-IT workforce already uses low-code, no-code or natural-language tools to create or modify applications. A further 22.3 percent put that share between 40 and 60 percent. Whatever gatekeeping IT used to provide on this question, it no longer sits with IT.

Keith Kirkpatrick, who led the study, named what enterprise vendors actually sell, and it is the part that quietly disappears from the business case. He locates their "compounding advantages" in four places: designing workflows that span organisational boundaries, owning the software maintenance lifecycle, purpose-built security and data privacy controls, and managing third-party integrations. Those four things do not arrive with a self-built tool, and nobody budgets for them when the licence is cancelled.

The companies furthest ahead are hitting it first

The clearest evidence that this bill comes due sits in the same McKinsey data. High performers are twice as likely as others to report scaling coding agents, and they are also the group that has skipped the most software purchases. Eighteen percent of them say cost has constrained their use of coding agents, against 6 percent of everyone else. On every other category of AI tool, from chatbots to other agents to specialised tools, the two groups sit within a point or two of each other. The cost pressure is specific to what they built. ^[1]

Read together, the two findings form a clear pattern. The organisations furthest along the build path are simply the first to arrive at the running cost of what they built, and everyone else gets there later. That is what the business case usually misses: a licence price already contains maintenance, security, upgrades and integrations, so it is a running cost. A build estimate contains the build. The arithmetic that says building beats buying compares a recurring number with a one-off one, and it holds right up to the day the thing goes into production.

In Europe, the build also changes your legal role

There is a second cost that almost never appears in the business case, and it is specific to this market. Under the EU AI Act, buying a system makes you a deployer, with the comparatively contained obligations of Article 26. Building it and putting it into service yourself makes you the provider, and provider obligations under Article 16 ^[3] are of a different order: conformity assessment, technical documentation, a quality management system, registration in the EU database and post-market monitoring.

This only applies to high-risk systems under Annex III, and most internal tools will not be in scope. Annex III ^[4] is far from exotic territory, though. Recruitment and candidate filtering, task allocation, worker evaluation and creditworthiness assessment are all on the list. A team that rebuilds the CV-screening function of an HR suite in two sprints has moved the organisation into a regulatory role it did not previously hold, with obligations that apply from 2 December 2027, rather than saving a licence fee. That is time to prepare, not time to ignore.

What to do about it

If you carry budget responsibility, this decision belongs to you rather than to IT, because the cost of the build shows up in your line and the consequence shows up in your operating model. The intervention required is small.

Name the body that holds the decision. In the operating models we design, make-or-buy above a threshold sits with a small standing group rather than a single role: budget responsibility, IT and risk in one room, meeting often enough that it never stalls a sprint. It is the logic of the old investment committee, applied to a decision that used to arrive with a contract attached and now arrives without one.

Define the threshold so that anyone can check it without estimating anything. Two triggers do most of the work: the build replaces a licence you hold or planned to hold, or it touches customer or personnel data or an Annex III use case. Either one, and the decision goes to that group in writing, answering three questions.

Does this workflow differentiate us in the market, or is it standard? Standard workflows are where vendors hold decades of accumulated advantage, and where a build mostly buys you ownership of a problem somebody else has already solved.

Who owns this in year three, when the person who wrote it has left? If the answer is a name, write it down. If the answer is a shrug, you have postponed a decision rather than made one.

What does it cost to run, as opposed to build? Token spend, maintenance, security reviews, integration upkeep, on-call duty and the documentation nobody wrote. The high performer data suggests this third question is systematically asked too late.

Where Dreamleap comes in

Two parts of this are our daily work. The first is the least glamorous part of an AI Operating Model: decision rights. Naming who holds make-or-buy, at what threshold and against which criteria takes a workshop rather than a transformation programme, and it is one of the few governance moves that pays for itself in the first year.

The second is what happens after the decision, and we sit on both sides of it. We build end-to-end agentic workflows ourselves, on a Swiss-hosted platform that connects to the systems where the work actually lives. That is why we know exactly what the running cost of a build looks like and where it hides. The same knowledge makes us useful when the honest answer is to buy, because it shows which standard workflows are not worth owning. We are not arguing for one side of the decision. We are arguing that somebody should make it deliberately, with the operating consequences on the table. If you are looking at a list of cancelled software licences and are not sure what your organisation now owns, that is a conversation worth having.

A third of companies have skipped a software purchase they would once have made, and almost none of them held a meeting about it. No individual failed here. This is what happens when a decision becomes technically trivial faster than the organisation notices it was ever a decision. Make-or-buy is a role rather than a tooling question. If nobody in your operating model holds that role today, the rule still exists, and it has quietly been delegated to whichever team has the largest token budget.

A question to take away: pick one piece of software your organisation stopped paying for this year because a team rebuilt it. Can you name who owns it, what it costs to run and what happens to it the week that person leaves?

This article was first published on 14 September 2026 in TransformAI, Julia Herz's LinkedIn newsletter on AI strategy, leadership and transformation. It has been revised for the blog.

About the author
Julia Herz is COO at Dreamleap. Together with her team, she accompanies organisations on their way to becoming AI-ready: through advisory, a secure agentic platform and enablement via the AI Academy.