Build vs Buy When Building Is Almost Free

On the twenty-fourth of March an email arrived that could have cost a client relationship. A partner had written to another business in the network claiming an arrangement with me that didn’t exist, and the forward landed in my inbox mid-morning looking like real trouble.

The system settled it in five minutes. Three email threads across five weeks, reconstructed and dated — who agreed what, when, in writing. The claimed arrangement wasn’t in any of them. I replied with the dates and the matter closed the same day.

But the incident proved a gap. Emails arrive that need business context to interpret — which client they touch, what’s actually agreed, what’s still open — and nothing in the system was providing that context on arrival. So I did what I do when a gap proves itself live: I wrote the brief. The build even had a name — Diego, the email awareness layer. MX record changes, inbound webhooks, a three-bucket routing layer, a pre-computed lookup table of every client and agreement in the business. Clean architecture, no new infrastructure, two sessions of work. Every signal said build it now.

And then I asked myself: would it be simpler to use a helpdesk app?

Build vs Buy Used to Ask Itself

Build vs buy used to be a question with the friction built in. Building meant a quote, a timeline, a developer, a budget conversation — the cost was the gate, and the gate did the thinking for you. You only built when the off-the-shelf option genuinely couldn’t do the job, because building hurt.

AI removed the friction. Two sessions and Diego exists. I’ve written about what that velocity does to client service — the same velocity applies to internal tools, and that’s where it gets dangerous, because the gate is gone and nothing replaced it.

Building the wrong thing is still expensive when the building is fast. Cheap to build is not cheap to own — whatever ships has to be maintained, documented, and understood by every future session that touches it. And the opportunity cost is real: you’ve just spent two sessions building something Freshdesk gives away with a signup form.

That moment is precisely when the question is hardest to ask. The brief is ready. The incident proved the need. The architecture is clean. Momentum is a cluster — one good signal and the assumptions gather round it until the decision feels already made. The junior instinct is to build; the senior instinct is to ask whether this problem already has a solved version. The pause is the entire skill, and it has to happen at full speed or it doesn’t happen at all.

Which Layer Is Actually Yours

Here’s what the pause surfaced. A helpdesk solves the routing. It doesn’t solve the reasoning.

A helpdesk can put the partner’s email in the right queue, tag it, assign it, escalate it. What it can’t do is read that email and say “no agreement exists for this client” — because that answer doesn’t live in the email. It lives in the business: the invoices, the threads, the records of what was actually agreed. Routing is a commodity, and you should never build a commodity. Reasoning against business state is the edge, and you can’t buy it, because no vendor has your context to reason with.

So build vs buy was never the real question. The real question was which layer of the problem is commodity and which is edge — and that distinction only surfaces if you stop long enough to look for it.

Four Lines of Code

Then the strip-back, and this is the part I’d rather skip and won’t. The MX record changes went first — the email already arrives, nothing needed re-plumbing. The webhooks went next. Then the three-bucket routing layer, because once you’re not running a helpdesk you don’t need a sorting office. What remained, after all that architecture fell away, was wiring data that already existed into a command that already existed. Four lines of code.

The forensics that settled the original incident — five weeks of threads reconstructed in five minutes — already worked. The awareness I was about to spend two sessions building was mostly already there, which I’d have seen sooner if I’d asked what the system already had before designing what it didn’t. Knowing what you’ve already built turns out to be half of knowing what to build next.

The brief was good. The incident was real. The architecture would have worked. None of that makes the build right, and that’s the uncomfortable shape of the new build vs buy: every signal that used to mean “go” still fires, but the one signal that used to stop you — the cost — is gone. You have to supply the stop yourself.

The most useful thing I built that week was four lines long. The most senior thing I did was ask the question that made the other two sessions unnecessary.

Read more about the system:

• The Moment I Stopped Clicking Buttons
• The AI Memory Problem Nobody’s Solving
• Anyone Can Use AI. The Art Is Situating It.
• The Correction Loop
• Ingeniculture

If you want this kind of thinking applied to your business — here’s how I work with clients, or get in touch.