Build vs. buy is often a scoping fight

An internal AI build rarely competes with the full product a vendor has built.

It competes with the smallest version of the problem the organisation thinks it needs to solve.

That makes build-vs-buy discussions less about whether something can technically be built and more about whether both sides are solving the same problem.

This distinction matters more now because AI has made the first version of almost anything dramatically easier to build. A small internal app, workflow or agent that would have required engineering resources a few years ago can now be prototyped in hours.

That is genuinely useful. It also changes the economics of software.

But I think it creates a new kind of mistake: comparing the cost of building a narrow prototype with the cost of buying a product that is responsible for a much broader set of problems.

The internal build often looks cheaper because it has quietly removed most of the scope.

The internal project usually starts with the happy path

Imagine a team is evaluating software that helps salespeople understand what is happening in active deals.

The vendor product might connect to the CRM, email and meeting transcripts. It maintains context over time, handles permissions, understands associations between accounts and opportunities, works across different CRM configurations, deals with missing data and provides workflows for sellers and managers.

The internal alternative might start with a much simpler requirement:

Can we ask Claude to read our CRM and meeting transcripts and tell us what is happening in a deal?

The answer is probably yes.

At that point, the build option looks extremely attractive.

A developer or technically minded operator can connect the systems, write some prompts and get a convincing result surprisingly quickly. The initial demo may even look almost identical to the output produced by the commercial product.

But the two things are not necessarily solving the same problem.

The prototype has proved that the core capability is possible. It has not yet proved that the company wants to operate it every day.

The next questions tend to appear later.

Which opportunity does this meeting belong to?

What happens when one customer has three active deals?

Which email threads are relevant?

What happens when the CRM data is incomplete?

How do we know which information is newer when the CRM and meeting transcript disagree?

What can one salesperson see about another salesperson’s accounts?

How do we know whether the output is still reliable after the underlying model changes?

Who notices when one integration quietly stops syncing?

None of these problems make the original prototype less impressive. They simply reveal that the actual scope was larger than the first question suggested.

Building the first version is no longer the hard part

This is where I think a lot of the current “AI will kill SaaS” discussion goes wrong.

The argument usually starts from something true: building software has become much easier.

I agree.

For small, well-defined and low-risk internal use cases, companies will probably build much more themselves. There are countless workflows where paying for another SaaS subscription makes less sense than putting together a lightweight internal tool.

I already do versions of this in my own work. If I need to transform some data, connect two systems or automate a repetitive process, the threshold for building something is much lower than it used to be.

But the first version is only one part of the cost of software.

We already know this from spreadsheets.

Almost every company has a spreadsheet somewhere that became critical infrastructure by accident. Someone created it three years ago. It contains formulas, scripts and assumptions nobody fully understands anymore. It still works, so nobody wants to touch it.

AI makes it possible to create the software equivalent of that spreadsheet much faster.

The initial build becomes easier, while ownership remains.

Someone still needs to maintain the integrations, understand the architecture, deal with edge cases, manage access, fix things when they break and decide how the system should evolve as the business changes.

The second S in SaaS still matters: service.

Buying software means buying more than the current feature set. You are also paying someone else to keep the thing working.

That does not automatically make buying better. It just means maintenance belongs in the comparison.

Context is where many AI builds become real engineering

There is another part of the build-vs-buy discussion that I think is particularly easy to underestimate with AI: context.

A simple AI application can look almost magical when you give it a clean set of information and a well-defined task.

Real business environments are rarely that clean.

The useful information may live across CRM records, email, calls, documents and internal systems. Some of it is outdated. Some is duplicated. Some is wrong. Often the hardest problem is not getting the model to produce a good answer, but making sure it receives the correct context before it answers.

This is something I have become much more aware of through my current work around AI and sales systems.

A prototype might connect a general-purpose model directly to a CRM and meeting recorder. Technically, the model now has access to everything it needs.

But access is not the same as context.

It may still need to work out which records belong to which opportunity, what changed since the previous meeting, whether a CRM field is outdated and which parts of a six-month conversation are relevant to the current question.

The more important the workflow becomes, the more engineering tends to move away from the prompt itself and toward everything around it.

That is why “we can build this with AI” can be simultaneously correct and incomplete.

You can probably build the visible capability.

The harder question is what needs to exist behind it for that capability to be reliable.

Security and compliance do not disappear when you build

Security creates a similar scope difference.

When evaluating a vendor, organisations quite reasonably ask questions about access control, data processing, retention, security standards, subprocessors, audit logs and how customer information is protected.

When the alternative is an internal prototype, those requirements can sometimes disappear from the comparison.

But the risks have not disappeared.

They have simply changed owner.

If an internal AI system can read CRM records, customer emails and meeting transcripts, someone still needs to decide who can access what. Credentials have to be managed. Data needs to move between systems safely. Logs may contain sensitive information. Changes need to be controlled.

For a small internal utility with low-risk data, this may be completely manageable.

For a system sitting in the middle of a company’s revenue operation, the responsibility becomes much larger.

Again, this does not mean “always buy.”

It means the build option needs to carry the same scope as the buy option before the comparison becomes useful.

The build-vs-buy line is moving

I do think AI is moving the boundary.

There are tools companies buy today that they probably will build themselves in the future.

There are also SaaS products that will need to become much deeper to remain worth buying. A thin interface around functionality that customers can recreate in an afternoon will become difficult to defend.

That is healthy.

The useful question is where the boundary sits.

I would be much more inclined to build something when the workflow is narrow, internal, low-risk and relatively stable. If it breaks for a day and somebody can fix it manually, the maintenance burden may be completely reasonable.

I become more cautious when the system becomes critical to revenue, handles sensitive information, needs to work across many users or depends on a large amount of changing business context.

At that point, the internal project stops being just a build.

It becomes a product the company now owns.

And that is the part I think build-vs-buy discussions often miss.

The question is rarely:

Can we build this?

Increasingly, the answer will be yes.

The more useful questions are:

What exactly are we building?

What happens when the happy path ends?

Who owns it after the person who built version one moves on?

How much of the vendor’s scope are we actually recreating?

And do we want to operate this system continuously?

If those questions still point toward building, then building may be the right answer.

But at least then we are comparing the same problem.

Because build vs. buy is often not really a capability fight.

It is a scoping fight.