Build vs buy AI: the third path nobody mentions.

Build vs buy AI gets posed as a clean fork: write a cheque to a vendor, or staff a team and write the code. Both framings hide the same thing — who ends up owning the workflow, the evals, and the right to change the model under it. The decision that matters is not build or buy. It is whether the thing you run a year from now is an asset on your balance sheet or a subscription you cannot leave.

The classic framing assumes two mutually exclusive doors. Door one: buy a finished product and accept its shape. Door two: build from zero with a team you hire, manage, and retain. Stated that way, most teams pick "buy" because building feels slow and risky, then spend the next eighteen months discovering the product was never shaped like their business.

The binary is wrong because it conflates two separate decisions and pretends they are one. The first decision is who does the work. The second — the one that actually compounds — is who owns the result. You can buy the labour and still own the asset. You can also "build" with an in-house team and end up owning nothing transferable, because the knowledge walks out the door when the two engineers who understood it leave.

For AI specifically, a third variable breaks the binary outright: the model is not yours either way, and it moves. Whatever you buy or build sits on top of a foundation model that ships a stronger version every few months. The question is whether your architecture lets you swap the model under your own logic, or whether the swap is the vendor's decision to make on their timeline and their pricing.

Buying an off-the-shelf AI product is correct whenever the capability is genuinely undifferentiated for you. If the workflow is identical to ten thousand other companies and it is not how you win, do not build it. Transcription, generic support deflection, meeting notes, document OCR, a horizontal writing assistant — these are commodities. Owning a commodity buys you nothing; you just inherit the maintenance.

• The capability is a commodity, not a differentiator — every competitor has the same one and customers do not choose you for it.
• Requirements are stable and shallow — you need the thing to work, not to bend to a process only you run.
• Speed-to-first-value matters more than total cost over three years — you are validating, not committing.
• The vendor owns a data network effect you cannot replicate — fraud signals, spam corpora, and similar shared-data moats.

The honest test: if the product disappeared tomorrow and you had to switch, would it hurt your strategy or just your Tuesday? If the answer is "just my Tuesday," buy it and never think about it again. Buying becomes a trap only when the thing you bought quietly turns into the way your business runs — at which point you are renting your own operating model.

Building is the right call when the AI workflow is the differentiator — when the prompts, the tool definitions, the retrieval over your proprietary data, and the eval suite that proves it works are the product, not plumbing under it. If a customer chooses you because of how this works, it cannot live behind a vendor's feature flag.

The second case for build is integration depth. Off-the-shelf AI products live at the edge of your systems and reach in through whatever API surface they expose. The moment you need the model to act inside your domain — reading your schema, calling your internal services, respecting your authorisation rules — you are building. That is precisely the surface the Model Context Protocol exists to make tractable; an MCP server turns your internal tools into something a Claude agent can call safely, which is build-side work by definition.

Run each candidate workflow down this table before anyone writes a cheque or a line of code. Most real systems are a mix — buy the commodity edges, build the load-bearing core — and that mix is the point.

If a workflow lands in the right-hand column on strategic weight, integration, or data, it is build-side — even if buying would be faster this quarter. The cost of buying a load-bearing capability is paid later, in the migration you cannot afford and the roadmap you do not control.

The third path collapses the false trade-off: a senior studio builds it the way build-side work demands, and you own every artefact at the end — repository, prompts, evals, infrastructure-as-code, runbooks. You buy the labour and the speed of a finished product, and you keep the asset of a thing you built. No vendor sits between you and your own workflow.

This is not staff augmentation and it is not a black-box SaaS. It is the custom build delivered in short cycles by people who would read your code on a discovery call, where the deliverable is a working system plus the right and the ability to change it without us. Concretely, "you own it" means a few non-negotiables.

1. The code lives in your repository under your licence — not ours, not a platform's.
2. The eval suite ships with the system, so you can prove a change is safe without trusting anyone's word.
3. The model is a swappable dependency — the architecture is Claude-native by default, and the model choice is a config line you control.
4. The runbooks and infrastructure-as-code mean a different team could operate it if you ever wanted them to.

Being Claude-native is a deliberate default, not a lock-in. We build on Claude — the current model family is Claude Opus 4.8, Claude Sonnet 4.6, Claude Haiku 4.5, and Claude Fable 5, on a 1M-token context window — through the Messages API, the Model Context Protocol, the Claude Agent SDK, and Claude Code, and on AWS Bedrock or Google Vertex AI where your compliance posture wants it. Because the model sits behind your own logic and your own evals, choosing a different one later is your decision to make, not a rebuild.

The riskiest thing about an AI system is not that it is wrong once — it is that it drifts quietly while everyone assumes it still works. The defence against drift is an eval suite: a versioned set of cases with expected behaviour, run on every change and every model bump. Without it, "build vs buy" is moot, because you cannot tell whether either one is still doing its job.

This is where ownership stops being a contract clause and becomes operational. When the evals are yours, a model upgrade is a Tuesday: you run the suite, read the diff, and ship or hold. When the evals live inside a vendor, the same upgrade is a leap of faith — the model changed under your feature and you find out from a support ticket. Ownership of the eval harness is the difference between operating a system and hoping about one.

For governed environments the ownership question is sharper still: data residency, audit trails, and the right to run the whole thing inside your own boundary are not features you can bolt on after buying. Teams with that posture should read the sovereign AI approach, where own-it is a regulatory requirement rather than a preference. For the workflow-automation case specifically, the same logic drives our AI workflow automation work — the agent acts inside your systems, so the asset has to be inside your boundary too.

Buy looks cheap because the invoice is small and monthly. Build looks expensive because the cost is large and upfront. Both readings ignore the line that dominates over three years: what it costs to change direction. A small monthly fee on a load-bearing workflow is a large number when you eventually have to migrate off it; a larger upfront build is a small number when the thing keeps earning and you never migrate at all.

• Buy: low upfront, recurring fee that scales with usage, and a migration cost that lands exactly when leaving is hardest.
• Build in-house: high upfront, ongoing maintenance, and key-person risk when the people who understood it move on.
• Studio-built, you-own-it: bounded upfront in short cycles, an asset you can operate or hand off, and no exit toll because there is nothing to exit.

We deliberately keep this qualitative — model prices and benchmark numbers drift, and any figure printed here would be wrong by next quarter. The durable point is structural: an asset you own has no switching cost, and switching cost is where buy decisions on core workflows go to die. Our pricing reflects the bounded-cycle shape of the third path rather than an open-ended retainer.

Stop asking whether to build or buy. Ask whether the workflow is load-bearing, and then ask who owns it at the end. Buy the commodity edges without guilt. For the core — the part customers choose you for — take the path that ends with the asset in your repository, the evals in your suite, and the model as a dependency you control. That is the door the binary never shows you.