Narrative-first, evidence-driven

A renewal notice lands for a reporting tool the team has been paying for for years.

Three years ago, the choice would have been simple: keep paying the vendor.

Building the same thing internally would have taken too much time, engineering attention, and maintenance.

Now the team looks at the product, looks at its own stack, and realizes something has changed.

One developer with AI help can build most of what they actually use. An operations lead can fill in some of the workflow pieces with a low-code tool. The remaining gaps are annoying, but not forty-thousand-dollars-a-year annoying.

At renewal, the vendor does not lose to a rival.

It loses to its own customer.

What’s happening

For some categories of internal software, the old build-versus-buy line is moving.

That creates a different market mechanism from normal software competition. The vendor does not just lose a deal to another vendor. The buyer can leave the vendor category entirely.

That is what makes this different from the last post. This is not the harder-gates story. It is the category-exit story: the product still works, the vendor may still be competent, but the customer no longer needs a vendor here at all.

The tools most exposed are the ones that solved bounded internal problems when building was expensive: reporting dashboards, lightweight workflow tools, internal portals, connectors, niche administrative software.

That does not mean every company should build everything. It does mean more buyers can now ask a question that used to be unrealistic: is it finally cheaper to build this ourselves?

When that answer turns into yes often enough, the vendor market changes shape. Demand does not just move across vendors. Some of it disappears from the vendor market altogether.

Why it’s happening

Two things are happening at once.

First, AI coding tools lower the cost of internal builds for development teams. A senior engineer can stand up a workable internal tool much faster than before.

Second, low-code and AI-assisted tools let non-developers build some of the smaller applications that used to wait in an IT queue.

Third, AI built into development tooling — automated dependency updates, AI-assisted code review, smarter monitoring — is compressing the ongoing maintenance burden. The old case for buying was never just about avoiding the initial build. It was the full lifecycle: the 2am maintenance window, the upgrade cycle, the internal team that owns it forever. That care-and-feeding overhead is getting cheaper too.

That is what makes this different from a normal vendor competition story. The pressure is not only vendor versus vendor. It is vendor versus internal build.

And there is a useful distinction here: the dominant enterprise AI story in 2025 was still buy, not build, for AI applications specifically. This case is narrower. It is about some categories of ordinary internal software becoming easier to build than they used to be.

Why this matters

For buyers, this can be good.

If a team can replace an overpriced point solution with a better-fitting internal tool, that can mean lower costs, faster iteration, and less dependence on software that never quite matched the work anyway.

For vendors, though, this is a harsher kind of competition.

They are not just losing customers to a stronger rival. They may be losing the entire category of demand.

That matters for workers too. If senior teams absorb more internal build work with AI, and if non-developers absorb more simple tool requests before they ever hit the dev queue, the old junior path can narrow at the same time.

But the story is not just “fewer starter tasks.” Some of the work that moves in-house is bigger, messier, and more formative than the simpler tickets it replaces. In the good version, teams use that opening to bring junior people into real internal builds and let them learn on work that actually matters. In the bad version, seniors and tools absorb both layers at once and the learning path shrinks anyway.

A cheaper build threshold changes the market

They can still have satisfied customers. They can still have a decent product. They can still lose, because the customer no longer needs a vendor at all.

That is the distinctive pressure in this case.

The exposed vendors are often the ones whose value proposition depended on one fact: building the equivalent internally cost more than the subscription.

Once that stops being true, they are vulnerable in a new way. Software does not have to become easy in some abstract sense. It only has to get cheap enough that buying stops making sense for this category of problem.

What good looks like

What good looks like is not every company rebuilding the software stack from scratch.

It is a world where buyers can make the build-versus-buy choice deliberately, with clear ownership, realistic maintenance assumptions, and actual governance for internal tools.

It is also a world where AI improves the comparison process. Procurement should get better at asking what can be built internally, what should still be bought, and what risks come with each path. That helps buyers avoid lazy renewals and helps smaller vendors compete on real value instead of legacy inertia.

And if organizations do save money by building more internally, the gains should not stop at margin. Some of that capacity should show up in better apprenticeships, better tooling, and better work quality for the people doing the work.

What to do

If you are a buyer, pick one internal-software renewal and run the comparison explicitly: renew, switch, build, or go without. Do not assume the old answer is still the right one.

If you are a vendor in the exposed range, stress-test your product against the current internal build cost, not the one from three years ago. If your moat is convenience alone, that moat is getting thinner.

If you are a technical leader, do not let “we can build it now” become a shortcut around ownership, review, and maintenance. Internal software still needs a real steward.

And if you are trying to understand the market shift clearly, ask the blunt version: are vendors still competing inside the category, or is the category itself starting to shrink?

How to talk about it

“Some software vendors are not just competing with other vendors anymore. They are competing with their own customers’ ability to build.”

Or:

“AI can change the build-versus-buy threshold without changing the rest of the market. When that happens, vendors lose demand, not just deals.”

One steady action to take this week

Pick one internal tool your organization pays for and ask a blunt question: if we were making this decision fresh today, would we still buy it?

That question is simple enough to ask and specific enough to surface whether the old threshold is still doing the work.

Action ladder

Short term

• Buyers: Run one explicit comparison on a current tool: renew, switch, build, or go without.
• Technical leaders: If you think you can build it internally now, name the owner, maintenance path, and review process before calling it a win.

Medium term

• Companies: Create a lightweight build-versus-buy rubric so internal builds are compared deliberately instead of approved by vibe.
• Vendors: Stress-test your category against the current internal build threshold, not the one from three years ago.

Long term

• Leaders and institutions: If internal building really saves money, reinvest some of that gain into apprenticeships, maintainable internal tooling, and better governance instead of cashing it all out as margin.
• Procurement and finance teams: Stop treating build-versus-buy as a one-time technical choice. It is now an ongoing market-power and workforce-shaping decision.

Related reading

• AI Is Not One Thing
• When Building Gets Cheaper but Breaking In Doesn’t
• Don’t Win the Sprint and Lose the Bench
• Case study: The Moving Breadbox: AI and the Collapsing Build-vs-Buy Threshold