I'm becoming more and more convinced of one idea. Custom software, paired with specialised AI agents, will become a real path to replacing B2B SaaS. Maybe not completely, but at least to some extent.

Here's why I think that, and what the shift could look like.

Buying software has always been a compromise

When a company buys software, it rarely gets a perfect match. Instead, it picks the option that comes closest to what it needs. That tool may not solve every problem. It's simply the best of the available choices.

Then something interesting happens. Rather than the software adapting to the business, the business adapts to the software. Teams reshape their workflows and processes so they fit the tool.

Over time, the problem grows. The software keeps adding features and becomes bloated. Meanwhile, your team might only use about 30% of what it offers. In some cases, it can even reach a point where the software starts slowing progress down instead of speeding it up.

Why buying still made sense

So why do companies keep buying? Because building software is expensive. Or at least, it used to be.

When you weigh the cost of building against the cost of buying, the compromise of buying has usually been the smarter choice. In most cases, living with an imperfect tool was cheaper than creating your own.

That balance is starting to change.

Step one: "Bring your own AI"

Look at how most companies operate today. They already pay for one or more LLM providers. On top of that, they pay an extra usage fee for third-party software that makes API calls to those very same LLMs.

In other words, they're often paying twice for the same underlying AI.

The first step of this transition will fix that. It will be a "bring your own AI" model. Customers will be able to plug their own AI or LLMs directly into pre-built software, rather than paying a vendor to access it for them.

Step two: Custom software with a specialised agent

The next step goes further. As LLMs improve and get better and better at writing code, a new combination becomes possible:

Custom, pre-built software as the foundation, and
A specialised AI agent that deeply understands that codebase.

Together, these two can ship all the features a company actually needs.

A generic developer vs. your developer

Here's a simple way to think about it.

Tools like Claude Code or Cursor are like a generic software developer you hire from Upwork. They're good at what they do. But they're not your developer.

You have to explain the problems you're trying to solve. And even after you do, they still lack the bigger picture. They don't know your company context, your business goals, or your best practices.

We're heading towards something different: a specialised developer. This developer is an expert in your codebase, your business requirements, and your company context. They don't need a long briefing every time, because they already understand how your business works.

How the role of builders will change

This shift will also change what builders do. Their work will mostly move towards two things:

Maintaining these agents, so they stay accurate and useful.
Deeply understanding customer problems, so they know what is actually worth solving.

Where this shift will show up first

The change won't happen everywhere at once. It will appear first in internal-facing, workflow-heavy systems. These are areas where context matters more than polish.

Good examples include HR software and internal tools. In these systems, fitting the way your company really works is more valuable than a beautiful interface.

The comeback of open-source B2B software

I also believe we'll see a comeback of open-source B2B software.

This would be generic software with a basic set of features. Companies could use it as a base and build on top of it to suit their own needs. Agents that specialise in understanding that codebase would then maintain it, working alongside humans.

The second-order effects

There are several second-order impacts at play here. One stands out above the rest.

Organisational memory becomes the moat.

By organisational memory, I mean the accumulated understanding of why systems exist the way they do. This knowledge gets encoded in the codebases themselves and in the agents that maintain them. Over time, it becomes one of a company's most valuable and hardest-to-copy assets.

Maybe "Context Graphs" (from the recent essay) are part of the solution here. But it might also turn out to be something every company builds and maintains for itself, rather than a standalone product.