Whats the cost of integrating voice technology into an app

Voice integration sits in a strange position in most app budgets. Clients ask for it, developers quote for it, and somehow the number that lands in the proposal bears little relationship to what the build actually costs. We see this pattern regularly: a brief arrives with voice listed as a feature alongside push notifications and dark mode, priced accordingly, and then the project runs into the reality that voice is a different kind of problem entirely.

Voice integration is a wholesale shift in approach, an interaction model that rewrites how the whole product works.

The gap between what people expect to pay and what voice integration actually demands comes from a fundamental misunderstanding of where the cost lives. Connecting a microphone to a speech-to-text API is straightforward. Building an interaction model that feels natural, handles failure gracefully, and fits coherently inside an existing product is not. Those two things get conflated at the brief stage, and the budget suffers for it later.

What follows is a clear-eyed account of where voice integration costs come from, what drives them up, and how to scope the work so the number in the proposal matches the number on the final invoice. The figures, decisions, and missteps we describe here are drawn from real projects, because the only way to write usefully about cost is to account for what actually happened.

What voice integration actually costs: the real price ranges

Voice integration does not have a single price. It has a range, and the spread inside that range is wide enough to matter enormously at budgeting time. A basic integration, connecting an existing app to a cloud-based speech-to-text service and triggering pre-defined actions from recognised commands, sits somewhere between £8,000 and £25,000 depending on platform complexity and the number of commands supported.

A production voice agent, one that handles natural language, manages conversational context across multiple turns, and connects to live data sources, is a different proposition. According to RaftLabs, 2026, a production voice AI agent costs $35,000 to $80,000 to build, with the wide range driven by integration complexity rather than the AI model itself. That figure is self-reported by a vendor, so treat it as directionally correct rather than precise, but it aligns with what we see on projects where the interaction model is genuinely sophisticated.

What actually drives the range

The cost variables that move this number are consistent across projects. The interaction model, whether command-based or conversational, is the largest single driver. The third-party APIs required for speech recognition, natural language processing, and text-to-speech each carry their own integration costs and ongoing per-use pricing. The state of the existing codebase determines how much preparatory work is needed before voice can be added at all.

Why voice is priced wrong at the brief stage

The mispricing starts with how voice appears in a brief. It tends to arrive as a bullet point in a feature list, sitting alongside things that are genuinely comparable in scope, a filter system, a favourites function, a settings screen. Those features have predictable costs because their interaction model is already established. Voice does not share that property.

When a client comes to us with a suggested budget and a request to adjust our process to fit it rather than letting the process define the scope, we push back. We did this on a project where the client had already gathered quotes before approaching us and arrived with both a number and a suggested methodology. We convinced them to go through a proper discovery phase first. What that phase revealed changed the budget significantly, but it changed it accurately, which is a better outcome than discovering the gap mid-build.

The brief-stage mispricing happens because voice is quoted on its most visible component, the API call that converts speech to text, and the surrounding work is left uncosted. Dialogue design, error handling, accessibility for users with accents or speech differences, latency management, and the changes required to the existing navigation model all get absorbed later as overruns.

Before accepting any voice integration quote, ask the agency to list every component the cost covers. If dialogue design, error states, and latency handling are not on the list, the quote is incomplete.

The interaction model decision that changes everything

The single decision that most affects cost is also the one most often deferred: what kind of voice interaction is this actually going to be? Command-based voice, where the user says one of a fixed set of recognised phrases and the app responds with a pre-defined action, is a contained engineering problem. Conversational voice, where the user can speak naturally and the system maintains context across multiple exchanges, is categorically different.

The gap in complexity between those two models is not incremental. Command-based systems can be built with relatively modest integration work and tested against a finite set of inputs. Conversational systems require dialogue state management, intent recognition, entity extraction, fallback handling for misunderstood inputs, and a way of keeping context alive across turns. Each of those components adds cost and adds failure modes.

The interaction model decision belongs at the start of the project, not after the API is already connected.

Natural human conversation operates at roughly 200 ms between turns, according to Frontiers in Psychology, cross-linguistic analysis by Levinson and Torreira. The fastest commercial voice agent systems are benchmarked at 900 ms, according to an arXiv benchmark of production voice agents. That gap matters for the interaction model choice: a command-based system where latency is expected feels natural, and a conversational system where latency is expected feels broken. Designing around that gap requires decisions that shape the entire build, and they cannot be made after the work has started.

How late discovery inflates voice integration costs

The most reliable way to increase the cost of voice integration is to defer the discovery work. We have direct evidence for what this looks like in practice. On a dating app project focused on verified profiles and preventing automated accounts, the client chose to skip discovery for the messaging component and concentrate budget on the onboarding flow. The logic was understandable: onboarding felt like the core differentiator, and messaging felt like a standard feature.

What we built as a result was a generic messaging system that allowed automated messages and unverified interactions, directly contradicting the verification architecture in the onboarding. The mismatch between the rigorously verified entry point and the permissive messaging layer meant the entire messaging section had to be rewritten. That rewrite cost approximately £15,000 in additional budget and added two months to the timeline.

The same dynamic applies to voice. Skipping discovery on the interaction model, the dialogue design, and the integration architecture does not save budget. It defers the cost and attaches a penalty to it. Projects that skip discovery are significantly more likely to exceed budget, according to Devtimate's analysis of discovery phase outcomes, and the voice context gives that finding extra weight because the discovery work here uncovers decisions that genuinely change the engineering approach.

Run a dedicated discovery sprint for voice before any build begins. Two to three weeks of dialogue design and API evaluation costs far less than a rewrite at month four.

Third-party APIs, voice platforms, and the integration layer problem

Voice integration almost always involves at least three external services: a speech-to-text provider, a natural language understanding layer, and a text-to-speech engine for any verbal responses. Each of those has its own pricing model, its own latency profile, and its own constraints on what it can and cannot do. The integration layer that connects them to your product is where a significant portion of the hidden cost lives.

We worked through this problem on a proof-of-concept project for a company building an app to share memories with audio attached. The original plan involved Spotify for short audio clips. The problem was that Spotify lacked a robust API for clips, and users would have needed a Spotify account, which degraded the experience. We switched to Deezer, which had a robust API, supported clips without requiring user authentication, and allowed us to build a proof of concept where users could search a catalogue larger than Spotify's and attach audio within the app. The switch also opened an affiliate revenue stream: when users wanted a full track, there was an upsell to a Deezer subscription.

The lesson about API evaluation

The Deezer decision looks obvious in retrospect, but it was not obvious at the brief stage. Without a proper evaluation of what each API could actually support, the project would have committed to Spotify, built around its constraints, and discovered the clip limitation midway through build. API evaluation is the work that determines whether the integration is even possible at the price quoted.

On a separate project for an alcohol buying and selling platform, being forced to embed web elements rather than build a proper API layer added approximately 20% uplift in work across the entire project. Because the client wanted to hold the budget fixed, we had to drop features towards the end to compensate. That 20% did not appear anywhere in the original quote.

When retrofitting voice onto existing code is the expensive path

Adding voice to an existing product is technically possible in almost every case. Whether it is the sensible path depends heavily on what the existing codebase looks like and how voice needs to behave within it. When voice is treated as a layer applied on top of an existing navigation structure, the result is usually a voice experience that fights the product rather than extending it.

The navigation problem is the most common version of this. A product built around tap-based navigation has its information architecture organised around what is visible on screen. Voice navigation needs a different architecture: one organised around what can be expressed in a spoken command and retrieved without a visual reference point. Retrofitting voice onto a tap-first structure without addressing the underlying architecture produces an experience that technically works but feels wrong to use.

The codebase readiness question

Adding a new interaction layer on top of existing functional code requires careful management of the gap between design intent and what the code can support. On a wellness genetics product we worked on, the handoff went through an intermediary designer, adding distance between the intended experience and the implementation. That distance created significant rework. Voice integration has the same vulnerability at larger scale: the more established the codebase, the more explicit the architecture decisions need to be before build starts.

The honest assessment at the scoping stage is whether retrofitting serves the product or whether a defined voice module, built cleanly alongside the existing product rather than layered on top of it, produces a better result at lower long-term cost. Retrofitting feels cheaper in the proposal and costs more by the end.

What a proper scoping process reveals before build begins

A scoping process for voice integration surfaces four categories of decision that cannot safely be deferred to build. The first is the interaction model: command-based or conversational, and what the failure states look like when the system does not understand the input. The second is the API stack: which providers, what their constraints are, and whether the product concept is achievable within those constraints before any commitment is made.

The third is the data architecture: what information the voice layer needs to access, where that data lives, and what the latency implications are of retrieving it in real time. On a toll management project, we had to work through a similar set of questions around data access and API relationships with established operators. We made the case that a new product would struggle to negotiate API access with incumbents, and that the right move was to launch on a simpler model first and pursue deeper integrations once the platform had established credibility. The client accepted the staged approach. That kind of decision belongs in scoping, not in the middle of a sprint.

The fourth is the codebase readiness assessment, which determines whether voice can be built cleanly or whether preparatory work is needed first. A scoping process that covers all four of these produces a budget that holds. One that skips any of them produces a budget that grows.

Ask for a written API evaluation report before sign-off. If the agency cannot confirm that the required APIs support the product concept at the required scale and price point, the budget is based on assumptions rather than evidence.

The features that quietly disappear when voice is undercosted

When a voice integration project runs over budget, the client and the agency face a choice: extend the budget or reduce the scope. On projects where the client holds the budget fixed, scope reduction is the outcome, and the features that disappear tend to be the ones that determine whether voice is useful at all.

Error handling is the first casualty. When voice is undercosted, the budget for building graceful failure states, clear feedback when the system does not understand, and recovery paths when a command is misheard gets cut. What remains is a voice feature that fails silently or produces confusing results, which users stop using within a week.

We saw the budget-versus-features tension directly on the alcohol buying and selling platform project. The 20% uplift from embedding web elements instead of a proper API layer ate budget that had been allocated to features. With the client holding the overall budget fixed, features were dropped at the end of the project to compensate. The voice equivalent of that decision is dropping the dialogue design work, the accessibility testing, and the multi-turn context management, and shipping something that technically qualifies as voice integration but does not actually serve the user.

1. Error handling and failure state design
2. Multi-accent and speech variation testing
3. Multi-turn context management
4. Latency optimisation for the interaction model chosen
5. Accessibility review for users with speech differences

These are the items that disappear under budget pressure. They are also the items that determine whether voice integration improves the product or adds a broken feature to it.

How to budget for voice integration without getting burned

The budgeting approach that holds is built in stages, not as a single line item. The scoping and discovery phase should be costed and commissioned as a standalone piece of work, producing a specification detailed enough to get accurate build quotes. The build phase should be quoted against that specification, with the API costs, the dialogue design work, and the error state development all explicitly included.

The ongoing costs also belong in the budget from the start. Voice APIs are priced per use, and a product that handles significant volume will carry meaningful monthly API costs. Those are not development costs, but they are costs that a business needs to plan for before committing to voice as a feature.

The sports club app project is the clearest example we have of what happens when scope is allowed to grow without a corresponding budget conversation. We warned the client early that the budget would exhaust itself before anything reached the app store. The warnings were noted and ignored. What should have been in market within three to four months never reached the store after twelve to fourteen months. The budget roughly doubled. Every one of those outcomes was predicted and advised against before it happened.

Voice integration does not need to follow that path. It needs a budget built on what the integration actually requires, a discovery phase that produces real specifications, and a client willing to hear what the process recommends rather than fitting the process to a pre-decided number. The projects that go well are the ones where those three conditions are met.

Conclusion

Voice integration is a feature that requires an unusual degree of upfront clarity about what kind of voice experience is actually being built, what the existing code can support, and which APIs can genuinely deliver what the product needs. Without that clarity, the budget is a guess, and guesses in this area tend to be expensive ones.

The patterns we have described here repeat across projects: the underdeveloped brief that leaves the interaction model undefined, the skipped discovery that produces a rebuild at extra cost, the API assumptions that only get tested mid-build, the fixed budget that forces features to be dropped rather than properly built. None of these are inevitable. They are all the product of the same root problem, which is treating voice as a feature with a predictable cost rather than as an interaction model that demands its own scoping process.

A well-scoped voice integration produces a number that holds, a specification that guides the build, and a product that users actually engage with. That process starts before a line of code is written, and it starts with an honest conversation about what the product actually needs. If you are planning voice integration and want to understand what it genuinely costs for your product and your codebase, start that conversation with us.

Frequently Asked Questions