Building It In-House: What the Estimate Leaves Out

Most build-versus-buy pages are written by the buy side and reach the conclusion you would expect. Here is the part that is true anyway: a large number of organisations should build this, and the ones who should not are identifiable by a single property of the work rather than by their size or their engineering quality.

When building is clearly right

When the actions are reversible. An agent that drafts, summarises, proposes, or writes to a scratch environment can be wrong without anyone paying for it, and in that setting the fastest way to learn what the workflow actually needs is to build a rough version and use it. No design document will tell you what three weeks of real use will.

From the standard

“Granting LLMs unchecked autonomy to take action can lead to unintended consequences, jeopardizing reliability, privacy, and trust.”

It is also right when the capability itself is the point. If your strategy is to have agentic engineering in-house in three years, buying the first system delays that and teaches your team less. Building a narrow one badly and then rebuilding it is a legitimate way to acquire the skill, and it is how most durable internal platforms started.

What the estimate leaves out

Estimates get built from the parts people can picture. Prompts, tool definitions, a retrieval pipeline, an interface — these are concrete, they are what the team has read about, and they genuinely do produce a working demonstration in a few weeks. The demonstration is real. It is also roughly the first fifth of the work, and the remaining four fifths are invisible in it.

In the estimate	Discovered in review
Prompts and tool definitions	Execution isolation at the hypervisor, not the namespace
A retrieval pipeline	Identity federation — the agent acts as the human, not as a service account
An interface	A tool roster intersected per turn from that person’s role
Logging	Policy validated outside the model’s own channel
—	Approval pinned to a version token, replay refused
—	A trace that survives the seam between control and execution

Each line on the right exists because of a specific failure mode, and none of them can be retrofitted cleanly onto a prototype that already works. That is the expensive property: the substrate is not a layer you add later, it is a set of decisions about where code runs and whose authority it carries, and changing those means rebuilding the thing that currently demos well.

The cost nobody budgets: staying still

A built system is not finished when it ships. Model providers change behaviour between versions in ways that are not announced as breaking. Frameworks reorganise their abstractions. A retrieval strategy that worked at two hundred tables stops working at two thousand. Each of those is a re-validation rather than an upgrade, and in a regulated context re-validation is paperwork as well as engineering.

The honest framing is not build-versus-buy but where you want your best engineers standing in two years. Some organisations want them on the substrate because it is strategic. Most want them on the domain problem the substrate exists to serve.

A test that decides it

Write down the first action the system will take that you could not undo before lunch. If there is no such action, build it — you will learn more, spend less, and own the result. If there is one, the substrate is the project, the demo is not, and the decision is about who carries that work rather than whether it is needed.

A third option gets skipped too often: build the domain layer and take the substrate as source. Every engagement here includes full source transfer and infrastructure as code, which means the build-versus-buy question can be answered as both, and the part your team owns is the part that encodes your business rather than the part that encodes a threat model.