The software you just decided to own

Nearly a third of organisations have stopped buying software they would previously have bought, and built it instead. That is a portfolio decision, and almost nobody made it as one.

The figure comes from McKinsey's State of AI survey, published on 25 August from fieldwork run between 4 May and 8 June with 1,719 respondents across 97 countries. Thirty-two percent report that their organisation decided against purchasing at least one software product or feature because the functionality could be built in-house with agentic coding tools. It runs highest in technology and healthcare, then professional services, then energy and materials. Among the small group McKinsey calls high performers, the ones attributing at least five percent of EBIT to AI, it is closer to half.

Read that as a procurement number and it is unremarkable. Build versus buy has been a live argument for forty years and the answer moves when the cost of building moves. What makes it worth an hour of your attention is how the decision got made. A team needs one small capability. The quote comes back at some annual figure. Someone builds a working version in a fortnight. That build is cheap enough to clear every threshold that would have sent the purchase to architecture review, to a business case, or to a procurement process. Nothing was bypassed, because nothing triggered.

So the organisation acquires a permanent maintenance obligation through a route that has no step for recording one. The subscription line leaves the budget and shows up in the savings. The obligation that replaced it appears nowhere, because no budget has a line called software we now own forever.

The outside market that would normally absorb this kind of work is not forming at the pace the platform sales suggest. Salesforce reported Agentforce annual recurring revenue of 1.2 billion dollars in its first quarter results for fiscal 2027, released on 27 May, up 205 percent year over year, alongside 3.8 billion agentic work units delivered to date. On 21 August, The Register reported a TD Cowen survey of Salesforce implementation partners across the United States, Europe and Asia in which none of them saw Agentforce driving their bookings, and a third were meeting or beating their own targets against 43 percent the quarter before.

I want to be careful about what that pair shows. TD Cowen's own reading is that adoption is subdued, and a KeyBanc note in July was blunter still, reporting that customers felt the product was not there yet. Those are probably the better explanations for this particular case, and neither of them is my argument. The narrow thing the pair does establish is that an experienced implementation bench for agent work is not being built at the rate the licence numbers imply. If your plan for the software you have started owning is to hire the maintenance in later, it is worth checking that those people are being trained somewhere.

The strongest objection is that this is conservatism wearing a caution costume. If building genuinely became cheap, then moving with it is correct, and the thirty-two percent are simply right. I think that objection is correct. My claim is narrower and it is about governance rather than about the choice itself. The old build-or-buy decision passed through review because the build cost enough to need one. The new one sits under the threshold, so it escapes the review without anyone deciding that it should. A commitment does not stop being a commitment because it arrived cheaply.

What I would do is ask for the list rather than write a policy. Every team that chose in the last twelve months to build something it would previously have bought, one line each. Most organisations can assemble that in a week and have never assembled it once. Then set two questions against each line, neither of which needs budget or permission. Who patches this when the model or the library underneath it changes, and what happens when the person who wrote it leaves. Where both answers are uncomfortable, that item belongs in the same review the purchase would have faced. Set the threshold on ongoing obligation rather than on build effort, because build effort is the thing that just stopped being informative.

Which piece of software does your organisation now own because building it was cheaper than buying it, and who is expected to be maintaining it in three years?