Building a voice AI agent in-house costs more than the first working demo. Total cost of ownership includes ongoing data operations, QA at production scale, and per-language rebuild work — categories a first-year build estimate usually skips. In our own rolling 90-day loss data, 2 of 16 genuine buyer losses chose to build in-house.

Why does an in-house voice AI build usually cost more than the first estimate?
Because the first estimate prices the demo, not the system. A working prototype that handles a clean, scripted call is a few months of engineering. A system that holds up on a messy real call, in six languages, at production volume, with a compliance team reviewing every script change, is a different and much longer project.
The gap between those two isn’t visible until month eight or nine, when the team that shipped the demo is now maintaining it, retraining it, and fielding edge cases nobody scoped.
What do buyers underestimate when they price a build against a vendor?
Two things, almost every time: data operations and QA at scale. A vendor’s per-minute price already has both baked in, covering the ongoing work of correcting mispronunciations, retraining on drift, and running QA against thousands of calls a day. A build estimate usually prices the engineering team and stops there.
The result is a comparison that looks close on paper and isn’t close in practice, because one side of the comparison is missing line items the other side has been paying for the whole time.
How many companies that evaluate us end up building it themselves?
Two, out of sixteen genuine closed-lost deals in our rolling 90-day window (win-loss-log.md, pulled 2026-09-28). That’s a real number, not a scare figure: most losses in that window went to a named competitor or to a prospect who went quiet, four each.
The two build decisions are worth attention out of proportion to their count, because a build decision is rarely revisited once a team has a year of engineering sunk into it. A competitor loss can come back around at the next renewal. A build decision mostly stays built, for better or worse.
What does a fair total-cost-of-ownership comparison actually measure?
Four categories, compared like for like, over multiple years rather than the first year:
| Category | Build in-house | Buy specialist |
|---|---|---|
| Engineering headcount | Dedicated internal build and maintenance team | Vendor platform plus internal integration oversight |
| Data operations and QA | Internal ongoing data, retraining, and QA operations | Included specialist scope to verify |
| Language coverage | Per-language and dialect build and upkeep | Existing coverage to validate |
| Time to first live call | 6–12 months | Weeks for specialist integration (illustrative) |
When does building in-house actually make sense?
When the volume is genuinely large enough to amortise the ongoing cost, and the use case is narrow enough that maintenance stays small. A large bank running a single, stable, high-volume flow with an in-house team already doing MLOps for other products is a real case for building. A team standing up its first voice AI use case, across multiple languages, with no existing speech infrastructure, is a much weaker one.
What should you ask before committing to either path?
Ask for the total cost of ownership over three years, not the first year. Ask whether the build estimate includes data operations and QA headcount, and whether those are people who exist on the team today or people still to be hired. Ask a vendor to run your own numbers live in front of you, rather than showing a reference deck built on someone else’s five figures.
If you are evaluating for regulated customer journeys, review practical deployment context in BFSI workflows, then run a dated live comparison using this vendor scorecard.
Total cost of ownership, in this context, is every cost a voice AI system creates after the first successful demo call: data operations, ongoing QA, retraining, and per-language rebuild work, measured over multiple years rather than the cost of reaching that first working call.
Key takeaways
- A rolling 90-day pull of genuine closed-lost deals found 2 of 16 losses went to an in-house build decision (win-loss-log.md, pulled 2026-09-28).
- The other 14 split between a named competitor (4), no response (4), and other stated reasons (6: project on hold, no current requirement, SPOC departure, and similar).
- Data operations and QA at production scale are the two cost lines a first-year build estimate most often omits.
- Language and dialect coverage gets rebuilt separately for each one in-house; a specialist vendor typically already has several live.
- Time to a first live call on a build path commonly runs 6 to 12 months, against weeks for a specialist integration.
Frequently asked questions
Is buying always cheaper than building a voice AI agent in-house?
No. At genuinely large, stable volume with an existing MLOps team, building can be the right call; the comparison only breaks down when a first-year build estimate is measured against a multi-year vendor total cost.
What’s a realistic timeline to build a production voice AI system from scratch?
Commonly 6 to 12 months to a genuinely production-ready system across languages and edge cases, against weeks for a specialist integration, per industry cost-of-ownership analysis (Cohere, 2026) and this quarter’s own loss pattern.
Does a vendor’s per-minute price already include QA and data operations?
For a specialist vendor, yes, that is what the per-minute price is pricing. Confirm it explicitly before comparing it to an internal engineering estimate that may not include the equivalent.
How do we compare build vs buy without seeing a competitor’s actual numbers?
Score what a vendor shows you live, against your own volumes, rather than comparing a reference deck to an internal estimate. That is the entire premise of the vendor scorecard linked below.