Build vs Buy Just Flipped: Coding Agents Broke the Procurement Case

Investors have reported founders replacing entire software categories with internal builds and cancelling the corresponding subscriptions. That behaviour was not economical two years ago. Coding agents changed the initial build cost by an order of magnitude, and they did almost nothing to the three-year maintenance cost, which is where the buy case has always actually lived.

What actually changed

For twenty years the build versus buy calculation had a stable shape. Building took months of engineering time you did not have, so you bought unless the requirement was genuinely unique.

Coding agents compressed the first half of that. A capable engineer can now produce a working internal tool in days where it previously took a quarter, and the tool is frequently good enough for the specific job.

That is a real change and it deserves to be taken seriously rather than dismissed. Investors have reported founders replacing entire tool categories this way and cancelling the subscriptions, which is behaviour rather than speculation.

What did not change is everything that happens after launch. An agent writes the code. It does not attend the security review, respond to the incident at 2am, migrate the schema, or explain to the auditor how access is controlled.

The build case, stated fairly

Three arguments, all legitimate.

The three arguments

Fit. An internal tool does exactly what you need and nothing else. No unused features, no workflow compromises, no waiting for a vendor roadmap to reach your requirement.

Data control. Nothing leaves your environment. For companies with genuine data sensitivity, this is worth more than any feature comparison.

Cost at the margin. A tool serving 200 internal users costs nothing per additional user. A per-seat subscription costs a great deal, and the gap compounds with headcount.

Each of these is real. The build case is not naive and dismissing it as such is how vendors lose deals they should have won.

Why vendors underestimate this

Software companies have consistently dismissed internal building as amateur work that will be replaced within a year. That was correct for two decades and it is now a dangerous assumption.

The internal tools being built today are not worse than they were. They are produced faster, by people who understand the requirement exactly, and increasingly they are good enough. A vendor whose competitive response is scepticism about build quality has misread the change.

The costs the build case omits

Build decisions are almost always modelled against the first quarter, which is the period where building looks best. Here is the rest of it.

Maintenance is the dominant cost and it is invisible at decision time. APIs change, dependencies deprecate, edge cases surface, and every one of those consumes engineering time indefinitely.

Security and access control are not optional and rarely scoped. An internal tool touching customer data needs authentication, authorisation, logging and a review process. Vendors amortise that across all their customers. You do not.

Staff turnover is the failure mode nobody plans for. The engineer who built the tool leaves. The documentation is thin because it was a two-day project. The tool becomes something nobody wants to touch and everybody depends on.

Opportunity cost is the real number. Every engineering month spent maintaining an internal tool is a month not spent on the product customers pay for. That is the comparison, and it is almost never the one made.

The cost that never appears in a spreadsheet

There is a fifth cost and it is cultural. Every internal tool creates a small internal dependency, and enough of them create an engineering organisation that spends a meaningful share of its capacity maintaining infrastructure nobody chose deliberately.

The individual decisions are each defensible. The aggregate outcome is a team that ships more slowly than it did before, for reasons nobody can trace to any single build decision.

Who should build and who should not

The row that matters commercially is the third. Regulated enterprises with procurement processes, audit obligations and thousands of users represent the large majority of enterprise software revenue, and almost none of the build-versus-buy shift has reached them.

Extrapolating from a fifteen-person startup cancelling a subscription to a bank doing the same is the specific analytical error that drove the software repricing, examined in the piece on the software selloff.

The pattern across all four rows

What separates the build rows from the buy rows is not company size. It is whether anyone outside the building has to trust the tool.

A tool used by fifteen colleagues who can walk to the author's desk needs no formal access control, no audit trail and no documentation, because the organisation is the documentation. The moment that stops being true, the costs a vendor absorbs on your behalf become costs you absorb yourself.

That threshold arrives somewhere between fifty and a few hundred users in most organisations, and it arrives immediately in any regulated context regardless of size.

A decision test you can run in an hour

The third row is the one that separates a successful internal build from an expensive one. A tool with no named long-term owner is not a build decision. It is a deferred problem.

The clause buyers should ask for either way

Whichever direction you go, the negotiating position has improved. A vendor competing against a credible internal build option is more flexible than one who is not.

The two terms worth asking for are a shorter initial term, which preserves the option to build later, and a documented data extraction commitment at no additional cost on termination. Both are cheap for the vendor to grant and both remove the lock-in that makes a bad buy decision expensive.

Mentioning that you have evaluated building is legitimate leverage rather than a bluff, provided you have actually done the modelling. Vendors can tell the difference within one question.

What the evidence shows

The shift is real and its scope is narrower than the commentary suggests.

Gartner projects roughly 35% of point-product SaaS being replaced or absorbed by 2030, and cheap internal building is one of the mechanisms. That trend is examined in the analysis of point product absorption.

At the same time, enterprise application counts are still growing. The average enterprise ran 291 SaaS applications in 2025 against 110 in 2020. If internal building were displacing purchased software at scale, that number would be falling. It is rising.

The most defensible reading is that building has become viable for a specific and growing set of narrow, internal, low-risk tools, and remains impractical for everything with a compliance surface or a large user base.

That set will keep growing. The question for any software company is whether their category sits inside the growing set or outside it, and the answer usually depends on who the users are rather than on what the product does.

Where this analysis is weak

Three honest problems.

The maintenance cost argument is the vendor's argument and I have made it in the vendor's shape. It is true and it is also exactly what a software company would tell you, which means it deserves more scepticism than I have applied.

Agents are improving at maintenance as well as at initial construction. If an agent can diagnose a failure, patch a dependency and write the test, the maintenance argument weakens over time rather than holding steady.

And the three-year framing assumes the tool is still needed in three years. Plenty of internal tools solve a temporary problem, and a build that is abandoned after eighteen months never incurs the costs that make buying look better.

Frequently asked questions

Where to start this week

Take the last internal tool your team built and answer two questions.

How many engineering hours has it consumed since launch, including fixes, access requests and the conversation about who owns it? And who maintains it if the person who wrote it leaves next month?

Compare that honestly to the annual licence you avoided. Some tools will come out ahead and the exercise will tell you which kind, which is more useful than a general position on the question.

Then apply the finding forward. Write down the two or three characteristics shared by the builds that came out ahead, and use them as the test for the next decision rather than deciding case by case.

Teams that do this consistently end up with a short, boring rule, usually something close to build internal and low-risk, buy anything touching customers or auditors. Boring rules are what good procurement looks like, and they take about two hours to derive from your own history.

Related reading