They Hired Me to Build It. I Asked What If We Don't.

A company brought me in to help build an AI system. Early in the engagement I asked why we were building it.

Then the version that changed the room.

They were shocked. They had hired me to build the thing, and here I am asking whether the thing should exist.

When I come into a situation I give the best advice regardless of what it means for my pocket. This was one of those.

Their budget was half a million dollars.

Now look at who else is in that category. The incumbents shipping this capability have raised hundreds of millions to do it. Not to market it. To build it.

So the comparison is half a million of one team's time against a product with two or three orders of magnitude more engineering already sunk into it, plus years of edge cases found by real customers.

That is not a fair fight and it was never going to be. The half million does not buy you a competitor. It buys you a worse version of something that exists, delivered later.

Which is a fine trade, sometimes. It just has to be a trade you made on purpose.

Have we done a gap analysis?

They said gap analysis, why?

Have we looked at the tools already in the market? Is there something that does this, or at least comes close?

They hadn't. Nobody had looked.

And when we did look, there was a tool already on the market that got them close to where they wanted to be.

Not identical. Close. Close enough that the remaining distance was a fraction of the work, and the honest conversation became about that fraction instead of about the whole build.

Here's the part that generalises, because the reason was not laziness.

It was a compliance workflow.

Compliance feels like the thing you must own. It carries regulatory weight, somebody's name is on it, and handing it to a vendor feels like handing over the risk you were hired to hold.

So they jumped straight to building, and the feeling did the deciding.

That instinct is worth naming because it is almost always backwards. A vendor whose entire business is that compliance workflow has seen more regulatory edge cases in a quarter than you will see in five years. Owning the code is not the same as owning the outcome, and the feeling conflates them.

People hear the term and imagine a procurement spreadsheet. It's smaller and more useful than that.

You read the vendor's own claims like an engineer instead of like a buyer.

I did this recently on a tool somebody suggested for outbound. Their site said the product deploys hundreds of agents to score the internet, hit APIs, and enrich your leads.

Sit with that sentence. What is an agent here? Because if you have written any of this yourself, you know that "hundreds of agents scoring the internet" describes something you would otherwise call a fetch tool with a loop around it. Impressive noun, ordinary mechanism.

That is not an accusation of dishonesty. It is the same move as the distillation claim: technically defensible, engineered to produce a belief the reader cannot check.

So the analysis is two passes. What does this actually do, mechanically, once I strip the language? And what percentage of my requirement does that cover?

Answer those and the build-versus-buy conversation stops being about identity and starts being about a number.

I want to be honest that the question has a price, and some of it lands on me.

Before the next AI build, ask the two in order.

What if we just don't build it? Sit in the silence. If nobody can answer it with something specific, you have found the actual problem.

Has anyone run the gap analysis? Especially if the workflow feels too sensitive to buy. That feeling is the strongest signal that nobody checked.

The advice that's right regardless of what it means for my invoice: run the gap analysis first. It is the cheapest thing on the whole plan and it is the one people skip.

Chris