devdot
← All postsProduct ·

A Third of Companies Skipped a Software Purchase This Year Because They Could Just Build It

McKinsey found 32% of organizations passed on buying software in 2026 because agentic coding tools made building it internally viable. The build cost fell. The maintenance cost did not.

McKinsey''s State of AI 2026 survey has one number that should change how you plan next year''s budget. 32% of organizations skipped buying at least one software product or feature because they could build it internally with agentic coding tools instead. In the same survey, the share of large enterprises scaling agents in one or more functions jumped from 27% to 40%.

That is not a story about AI hype. That is procurement behaviour changing, and it happened fast.

The build cost fell. The other costs did not.

Here is where teams get this wrong. The number that dropped is the cost of getting to a working version one. An agent can scaffold an internal approvals tool, a reporting dashboard, or a customer portal in a few days of focused work. That used to be a quarter.

Version one was never the expensive part.

The expensive part is year two. Someone has to own that internal tool when the person who built it changes teams. Someone has to patch it when a dependency has a CVE. Someone has to keep its auth working when you migrate identity providers, extend it when finance wants a new field, and answer for it when it goes down during month end close. None of that got cheaper. If anything it got harder, because the code was generated quickly and nobody on the team has the deep familiarity you get from writing something by hand.

The vendor you did not buy from was absorbing all of that for a monthly fee.

The question is not build or buy. It is who carries it.

We tell clients to price a build over three years, not three weeks. Ask a few direct questions before you replace a SaaS line item:

  • Who is the named owner of this tool in 18 months, by name, not by team?
  • What happens on the day it breaks and that person is on holiday?
  • Is this thing on your critical path, or is it a convenience?
  • Does it touch customer data, payments, or auth? If yes, your real cost includes compliance and review, not just code.

If you cannot name an owner, you are not building software. You are creating a future incident with a nice UI.

Build the specific. Buy the boring.

The teams doing this well are not building everything. They are building the workflow that is genuinely theirs. The internal ops tool that matches how their business actually runs, the one that never fit the off the shelf product properly. That is a good build, and agentic tooling made it viable where it was previously not worth the engineering time.

They are still buying identity, payments, email delivery, error tracking and analytics. Those are commodity problems with mature vendors and real security teams behind them. Rebuilding them internally is how you end up maintaining a worse version of Auth0 for free.

The useful filter is differentiation. If a customer would never notice which vendor you used, buy it. If the thing encodes something specific about how you operate, build it, and staff it properly.

What to do this quarter

Take your SaaS spend and sort it into three buckets: undifferentiated infrastructure, workflow tools you have bent out of shape to fit your process, and things you actively love. The middle bucket is where the build case now makes sense. That is also where agentic tooling gives you the biggest leverage, because you already know exactly what the thing needs to do.

Start with one. Give it an owner and a maintenance budget on day one, not after the first outage.

We''re here to help founders and teams design and build digital products that are built to scale with you, not slow you down. If you''re looking to build something, get in contact with us today!

NEXT POST →The Median Engineer Now Runs Five AI Agents. Nobody Can Name Them All.