FIELD NOTES·ENGINEERING·8 MIN READ

{{ shareLabel }} Print {{ saveLabel }}

Two years ago, "build vs. buy" for AI was almost always a build conversation. The models were raw, the tooling was thin, and anything genuinely useful had to be assembled by hand. That is no longer true — and pretending otherwise is now the most expensive mistake we see teams make.

The reflex to build everything comes from a good place: control, differentiation, not wanting to be locked into a vendor. But most of what teams reach to build in 2026 is undifferentiated plumbing — retrieval, evaluation harnesses, prompt orchestration, guardrails. It feels like product. It is actually infrastructure, and it depreciates the moment a vendor ships the same thing as a checkbox.

So the question we ask on every project is narrower than "build or buy." It is: what part of this, if we got it exactly right, would a customer actually notice? Build that. Buy the rest.

The line falls on judgment, not code

The durable, buildable asset is rarely the model or the pipeline. It is the accumulated judgment about your domain — what "good" looks like, which failure modes are unacceptable, what your customers actually ask for at 2am. That lives in your evaluation set, your labeled data, and your taste. None of it is for sale, and all of it compounds.

"Own the judgment. Rent the machinery. The teams that flip that end up maintaining a worse version of something a vendor now gives away."

This is why our own Build AI practice leans on ready-made models and vendor APIs for the machinery, and spends the budget where it moves the needle — the evaluation loop, the data, and the last 10% of experience that makes a feature feel trustworthy instead of merely impressive.

The two ways teams get it wrong

Over-building. A team spends a quarter on a bespoke retrieval stack to save $400 a month in API costs, then spends the next quarter maintaining it. The build was real work; the value was negative.

Over-buying. The opposite failure: wiring together five SaaS tools into a workflow no competitor could tell apart, and wondering why the product has no moat. Buying is right for the machinery and wrong for the thing customers are paying you for.

The way out is boring and reliable: start with the smallest thing that could possibly ship, buy every part of it you can, and watch where reality pushes back. Wherever a bought component can't meet the bar your customers actually feel — that is your build. Everywhere else, there's impact and scale it from there.