Is a no-code voice AI platform cheaper than a custom build?

For the first few months, almost always yes. A no-code platform gets you a working agent in days with no build cost, and you pay per minute on top of a monthly plan. It stops being cheaper at one of two crossover points. The first is volume: per-minute platform pricing is a multiple of the raw model and telephony cost, so at high call volume the margin you are paying compounds every month with nothing to show for it. The second is scope: the moment you need something the builder does not expose — a specific handoff behavior, a stateful multi-step workflow against your own database, a custom latency optimization, a compliance requirement about where audio is stored — you either cannot do it or you pay for a custom escape hatch that costs more than owning the pipeline would have. The honest recommendation is to start on a platform to validate that customers will actually talk to the thing, and treat the migration to a custom build as a decision you make with real usage data rather than upfront.

What ongoing costs should I expect after launch?

Four buckets, and only the first is usually quoted. (1) Per-minute usage: telephony termination, speech-to-text, LLM tokens, and text-to-speech, each billed separately and each scaling directly with minutes of conversation. (2) Hosting and infrastructure: the media server and application tier have to stay warm to hit latency targets, so this is a fixed monthly floor rather than a usage curve, plus database, logging, and call-recording storage. (3) Maintenance: model deprecations, vendor API changes, prompt and behavior tuning against real transcripts, and the ordinary dependency and security upkeep any production service needs. (4) Observability and QA: somebody has to listen to calls and fix what goes wrong, which is a real recurring cost whether it shows up as a tool subscription or as staff time. Budget the usage cost per minute against your actual call volume and treat the rest as a fixed monthly number.

How long does a production voice agent typically take to build?

A single-use-case agent that answers one kind of call and does one thing well is a matter of days to a couple of weeks, most of which is not the pipeline — it is the conversational design, the failure handling, and the integration with whatever system needs to be read from or written to. A production multi-intent agent that handles several call types, escalates to a human cleanly, and holds up under real traffic is realistically several weeks, and the schedule is usually driven by iteration against real calls rather than by the initial build. Fully custom work — bespoke latency engineering, multi-language behavior, deep integration into an existing telephony estate — is measured in months and should be scoped in phases with something live at the end of the first one. The pattern that consistently blows schedules is treating launch as the finish line: the tuning loop after real callers arrive is not a bug-fix tail, it is a planned phase.

What an AI voice agent actually costs to build in 2026

A realistic cost breakdown for AI voice agents — build cost by tier, the ongoing per-minute and hosting costs nobody quotes upfront, and how retainers compare to a flat day rate.

Every quote you have been given for an AI voice agent is somewhere between $5,000 and $250,000, and every single one of them is defensible. That is the actual problem with this question. "How much does an AI voice agent cost" has the same shape as "how much does a building cost" — the honest answer depends entirely on whether you want a shed or a hospital, and most of the confusion in the market comes from vendors answering a different question than the one you asked.

So this page does not give you a number. It gives you the structure of the number: what drives cost up, which costs are one-time and which recur forever, and how the common pricing models compare when you run them out twelve months.

Why the generic answers are useless

Three things make the range so wide.

Scope is not linear. An agent that answers "what are your hours" and an agent that books an appointment against a live calendar are not 20% apart in effort. The first is a prompt and a phone number. The second has to hold state across turns, handle a caller who changes their mind halfway through, deal with a booking that fails after the caller was already told it worked, and decide what to do when the calendar API times out. Most of the cost in voice AI is in the failure paths, and failure paths scale with the number of things the agent can actually do.

"Working" and "production" are different products. A demo that handles the happy path can genuinely be built in a day. A version that survives a caller with a heavy accent, background noise, a bad line, someone who interrupts, someone who asks something out of scope, and someone who needs a human — that is most of the work, and it is invisible in every demo you have been shown.

Build cost and run cost get conflated. Voice AI has a real marginal cost per minute of conversation, which software people are not used to. A quote that covers only the build tells you nothing about what the thing costs to operate at your call volume, and at high volume the run cost dominates the build cost within the first year.

Build cost by tier

Three realistic tiers. The ranges are wide on purpose — narrow ranges in this market are marketing, not estimates.

Tier 1 — single use case

One intent, one outcome. Answers the phone after hours, captures the caller's details, sends them somewhere. Or qualifies inbound leads against three questions and routes them. No deep integrations, one language, a clean escalation path to voicemail or a human.

This is genuinely small. Days, not months, and the cost is dominated by conversational design and testing rather than engineering. If someone quotes you five figures for this shape of problem, ask what specifically is expensive about it.

Tier 2 — production multi-intent agent

Several call types handled by one agent, real integration with the systems of record (CRM, calendar, ticketing, ERP), a proper warm handoff to a human, logging and transcripts you can review, and latency tuned well enough that callers do not talk over it.

This is where most serious projects land, and it is where the estimate spread is widest, because the integration surface is the variable. Talking to a modern REST API with good docs is a fraction of the work of talking to an on-premise system with a SOAP interface and an ownership question. Scope the integrations before you scope the agent.

Tier 3 — fully custom

Bespoke latency engineering, multi-language behavior, a large intent surface, deep integration into an existing telephony estate, compliance requirements about audio retention and data residency, or unusual voice work. Measured in months, and correctly scoped in phases where each phase ends with something in production.

Where the platform option sits

Below all three tiers there is a fourth option people forget to price: a hosted voice-agent platform where you configure rather than build. Build cost is effectively zero, time-to-live is days, and you pay a monthly plan plus a per-minute rate that bundles every component. For validating whether your callers will talk to a machine at all, it is almost always the correct first spend, and treating it as a throwaway is fine — the artifact worth keeping from that phase is the transcripts, not the configuration.

It stops being the cheap option at volume, because the bundled per-minute rate carries the platform's margin on top of every underlying component, and that margin compounds monthly with nothing accruing to you. The crossover point is arithmetic, not ideology: work out the monthly delta between platform pricing and raw component cost at your real volume, and compare it to the one-time build cost. If the build pays for itself inside a year, build.

The useful sanity check across all three tiers: ask any vendor to break the estimate into pipeline, integrations, conversational design, and post-launch tuning. If they cannot, the number is a guess wearing a suit.

The cost nobody quotes: what it costs to run

Build cost is the number people negotiate. Run cost is the number that shows up forever. It has two shapes.

Per-minute usage. Four vendors bill you for every minute of conversation:

Component	What it does	Billing shape
Telephony / CPaaS	Terminates the call, streams audio	Per minute, inbound and outbound priced separately
Speech-to-text	Transcribes the caller in real time	Per minute of audio
LLM	The reasoning turn	Per token, which converts to a per-minute figure that depends heavily on how much context you carry
Text-to-speech	Speaks the reply	Per character or per minute, and premium voices cost multiples of standard ones

The LLM line is the one that surprises people, because it is not really per-minute at all. It scales with how much conversation history and retrieved context you stuff into each turn. Two agents with identical call volume can differ several-fold on model cost purely because one of them re-sends the entire transcript on every turn and the other summarizes.

Fixed monthly. Hosting that stays warm (cold starts are fatal to latency), database, log and recording storage, monitoring, and maintenance. Maintenance is real recurring engineering: models get deprecated on the vendor's schedule rather than yours, APIs change, and prompts drift out of tune as your business changes. A voice agent nobody maintains degrades quietly — it does not break, it just gets worse at its job while everyone assumes it is fine.

Run the arithmetic before you commission the build: estimated monthly minutes × blended per-minute cost, plus the fixed floor. If that number is uncomfortable at your projected volume, the build scope is the wrong conversation to be having.

The five things that actually move the number

If you want to change what a voice agent costs, these are the levers, roughly in order of how much they matter.

1. The number of things the agent can do. Not the number of things it can say — the number of actions it can take against a real system. Each one brings its own error handling, its own confirmation step, and its own "what do we tell the caller when this fails after we already promised it" problem. Going from one action to three is not three times the work, but it is not 1.2 times either.

2. The integration surface. A well-documented REST API with a sandbox is a rounding error. A legacy system with no test environment, undocumented behavior, and an internal owner who is busy is the single most reliable source of schedule overrun in this entire category of work. Find out which one you have before anyone quotes.

3. Latency requirements. Being under a second end-to-end and being under three seconds are different engineering projects. Streaming everything, keeping infrastructure warm, choosing models for time-to-first-token rather than benchmark scores, and handling barge-in properly are all real work, and they are only worth paying for if your callers will actually hang up. For an after-hours message-taker, they will not.

4. Languages. Each additional language multiplies the testing matrix, and the hard part is not translation — it is detection, code-switching, voice quality, and the fact that your evaluation set now needs native speakers.

5. Compliance and data handling. Recording consent, audio retention, where transcripts live, whether the model provider can train on your calls, sector-specific rules. This is usually cheap to design in and expensive to retrofit, which makes it the one item worth over-specifying early.

Notice what is not on that list: the choice of model, the choice of TTS voice, and the choice of framework. Those are decisions, not costs. Teams spend weeks on them and they are close to free relative to everything above.

Retainer vs. flat day rate

Most agencies price this as a monthly retainer with a minimum term. That model is genuinely good at some things — it buys you continuity, a named team, and someone on the hook when a vendor changes an API at 2am. It is bad at one specific thing, which is that it decouples what you pay from what gets built. You are buying capacity, and capacity gets consumed by coordination as easily as by code.

The flat day rate inverts that. The rate here is $1,000 a day — design, build, integration, deployment, all of it, no separate line items and no account manager layer. You know what a day costs before it starts, and the estimate is denominated in a unit you can verify: days of work, with something running at the end of the first week.

The practical difference is in how the two models handle scope changes. In a retainer, adding a requirement is a conversation about whether it fits in the current sprint, and the cost of it is invisible. At a day rate, adding a requirement is a conversation about how many days it adds, which is a number you can decide about. Neither is more honest in principle. One is just easier to audit.

Where retainers genuinely win: when you need multiple people working in parallel, when you need coverage across time zones, or when the risk of a single person being unavailable is unacceptable to your business. That tradeoff is worked through properly in the freelancer vs. agency comparison.

A worked example: LastWorker

LastWorker is a useful illustrative case because its scope is public: it answers phone calls, chats, texts, and email, around the clock, across 97 languages.

Read as a costing exercise, the scope decomposes like this. The pipeline itself — telephony in, streaming transcription, model reasoning, speech back out — is the smallest line item, and that surprises people. The expensive parts are the ones the scope statement implies rather than states: four channels means four sets of conversational conventions, not one agent with four front doors; 24/7 means the failure handling has to work with nobody watching; and multi-language means language detection, code-switching mid-sentence, voice selection per language, and holding latency budget while the model reasons in one language and speaks in another.

The lesson to take from it is a scoping lesson rather than a price. Every clause in a voice agent brief that sounds like a feature is usually a cost centre with its own failure modes attached. "And it should handle Spanish too" is not a translation task. "And it should text them afterwards" is a second product surface. Price the clauses, not the sentence.

The engineering detail behind the latency and handoff problems is in the case study; the same plumbing applied to non-voice problems is the AI agents and automations work.

How to sanity-check any quote you receive

Five questions that separate a real estimate from a number:

What is the per-minute all-in cost at my expected volume? If they cannot break it into telephony, STT, LLM, and TTS, they have not costed it.
What happens when the model I am built on is deprecated? Whose budget is that, and is it in the quote?
How many hours of post-launch tuning are included? Tuning against real calls is a phase, not a warranty claim.
Who owns the prompts, the integrations, and the call data? On some platforms the answer is not you, and that changes the migration cost later.
What is the escalation path when the agent fails? An agent with no clean handoff to a human is not cheaper, it just moves the cost onto your customers.

The right first move for most businesses is still the boring one: prove that callers will engage with an agent at all, on the cheapest thing that can prove it, and let the real usage data decide what the custom build needs to be. Scope grows honestly from evidence. It grows expensively from imagination.