Log inBook a demo
Market Insights

Build vs buy: what an in-app agent really costs to own

Wiring a speech API to a model takes an afternoon. The nine workstreams that turn it into something you can hand to a user do not have an end date.

VVoqal · Engineering10 min readPart of Business

About this article

Any competent engineer can point a speech API at a model and have something talking back before the end of the day. That prototype is what produces the estimate of a few weeks, and the estimate is honest about the thing it measured. It measured the prototype.

The four boxes on top are what a prototype covers. The six inside the framed group decide whether the feature can be handed to a user.

The prototype does not handle a noisy room, a half-finished sentence, a user who interrupts, or a network blip in the middle of a turn. It does not know which of your endpoints it may call. It does not ask before it moves money. It has no opinion about what should appear on screen when the answer is a list of twelve transactions rather than a sentence. Each of those is separate work, and most of it only reveals itself once real people are using the thing.

The nine workstreams, and who owns each#

One row keeps the same owner in both columns. Everything else is a transfer of ownership, which is a smaller claim than a saving and a more defensible one.

Duration estimates for these are worth treating carefully. The version of this post that this one replaces carried a six-month total, and that figure traced to nothing. What follows is our own engineering experience of having built each row, offered as experience rather than as a survey: speech selection and fallback runs into weeks, the agent loop is fast to stand up and slow to make reliable, the widget layer grows one component at a time for as long as the product does, and the last two rows have no end date at all.

Naming and shaping the tools is the row that stays yours in both columns. Anthropic, writing about their own agents, put the ratio plainly: “We actually spent more time optimizing our tools than the overall prompt.” Their later guidance on tool design (11 September 2025) adds the correction most teams need early: “More tools don’t always lead to better outcomes.”

Where the seconds actually go#

The instinct is that a slow assistant means slow code. In our own measurements against a live merchant tenant, almost none of a turn is our code. It is round trips to services outside the process.

The two component timings below the rule overlap inside the cold path, so they do not add up to the 6.7 seconds above it. They are shown because they are where the cold path's time is spent.

The gap between those two bars is the whole of the latency engineering. A warm connection pool keeps the tool server’s session open instead of re-negotiating it, and a primed prompt cache means the model is not re-reading the system prompt from scratch. In our case a cache hit is the difference between a 6.7 second turn and a 2.5 second one.

A latency budget bar for a cold turn shrinking to a warm turn once the connection pool and prompt cache are warm
Animation: our own measured cold and warm turn budgets.

We have seen the same cold connect run past twenty seconds when the upstream tool server is having a bad day. That is worth stating plainly because it decides the architecture. When the slow part is not yours, speeding up your part buys nothing. The fix is holding connections open, caching what you are allowed to cache, and never being the first request of the day.

If you build this, you are not buying an agent. You are taking on the job of keeping four external services warm, indefinitely.

The boundary you would be signing up to own#

Your app, the SDK in it, and your own API stay yours either way. The dashed boundary is the part that changes hands, and it has four vendor relationships inside it.

Two things stay yours in both worlds. Your app is yours. Your API is yours, whether you expose it through the Model Context Protocol or an equivalent. What changes hands is the runtime in the middle and the three vendor relationships hanging off it. That is the thing to price, and it is easy to underprice because from the outside it looks like glue code.

The part nobody budgets: anything that writes#

The widget layer is the row people underestimate most, because it grows with the product rather than shipping once. Shipping UI without a release is the argument for moving that decision to the server instead of the binary.

A read-only assistant is a demo with better error handling. The moment it can settle a balance, send a payment link or change a delivery address, the shape of the problem changes. A transcript is not consent. The model has been wrong before and will be wrong again, and the cost of it being wrong is now measured in the user’s money.

The write path is two requests. The agent proposes; a separate call executes after the user agrees. That split is what makes a wrong tool call a recoverable moment instead of an incident.

The confirm step is a protocol rather than a dialog box. The turn that selects a write tool has to stop short of running it and return a description of what it would do. The client has to render that description as something a person can check. The approval has to be tiered, so a payment link is a tap and settling a balance is a biometric prompt. And the agent has to be stopped from naming the approval method in what it says out loud, because describing the security mechanism aloud teaches an attacker its shape.

The MCP specification makes the underlying reason explicit in its trust and safety section: “Tools represent arbitrary code execution and must be treated with appropriate caution”, and tool descriptions “should be considered untrusted, unless obtained from a trusted server”. Tiering approval by risk works through which actions earn which gate.

On the money#

Published cost estimates for this category exist and all of them come from companies who would like to build it for you. Biz4Group, an AI development agency, puts the range at “$20,000 to $50,000” for an MVP, “$50,000 to $100,000” for a mid-tier build and “$100,000 to $200,000” for enterprise scope, in a post updated 17 July 2026. Read it as a vendor’s price list rather than as an industry benchmark, because that is what it is.

Two of the other three inputs are checkable without anyone’s help. Per-minute speech pricing is published by the speech vendors themselves. A loaded engineer rate for your own market is a number your finance team already has.

The fourth input decides the answer and nobody publishes it: the maintenance tail. It depends on how many vendors you are keeping warm and how tolerant your users are of a bad afternoon, and it is the line that turns a one-off project cost into a permanent headcount. The ROI side of this works through what you can and cannot put a number on.

When building is the right call#

Buying is not always correct. Build in-house when at least one of these is true, and be honest about whether you are reaching for it.

The agent is the product. If you sell the assistant, or the speech layer is your differentiator, this stack is your moat and you have to own it.

You have a funded team that wants this job. Not an engineer who will look at it. A staffed group with a mandate to run it for years.

A requirement rules every vendor out. On-device inference for a regulated environment, a proprietary acoustic model trained on data you cannot share, or a latency floor below what any hosted pipeline reaches.

Volume changes the arithmetic. At sustained high volume, owning the pipeline can beat per-minute pricing. This is a late optimisation, after you have already paid the build cost, so it is not a reason to start.

The Voqal dashboard's deploy surface on the iOS install tab, showing a masked publishable key, the Swift Package Manager snippet, all five required delegate methods and the appearance editor.
What the buy path looks like from the inside: one package, one key, five delegate methods. The comparison worth making is this against the nine-row table above. The key is masked and the preview beside it runs on sample data.

The hybrid nobody writes down#

Most teams that end up building did not decide to. They adopted a runtime for the demo, hit one requirement it did not cover, wrote around it, and then wrote around the next one. Two quarters later they own a fork of somebody else’s architecture with none of the support.

The way to avoid that is to name the requirement that would force a build before you start, and check it against the vendor list on day one rather than in month four. If the requirement is real and unmet, build deliberately. If it turns out to be a preference, adopt and keep the engineers on your own product.

Three questions, answered honestly#

Is the agent the core of what we sell, or a feature on a product we already sell? Do we have a staffed team ready to own speech, tools, latency, security and on-call for years? Is there a requirement that rules every vendor out?

Feature, no, and no means buy, and it means the engineers stay on the work only you can do. Anything else means build with the ownership diagram pinned to the wall, so that when the maintenance tail arrives nobody is surprised by it.

Two things to read next. The full stack laid out end to end covers the five layers you would be building, and the runtime comparison covers who you would be buying from, including where they beat us.

Sources#

Filed underBuild vs buyProduct strategyAgentsLatency

Next

Plans, limits and what ships on each.

See what buying costs

The rest of Business

Open the cluster

Build versus buy, what an agent changes about activation and support load, and the measurements that tell you before the quarter ends.

Elsewhere on the map