Skip to content

Service 06

Migrating Off Vapi or Retell

You launched on a managed voice platform, it worked, and now latency, cost or control has become the ceiling. This is the rebuild onto a stack you own.

What this service covers

Vapi and Retell are good products and starting there is usually the right call. They get a working agent in front of customers in days rather than months. The ceiling arrives later, and it is nearly always one of four things: per-minute cost that stops making sense once volume is real, latency you cannot reduce because the pipeline is not yours, a model, voice or language the platform does not offer, or a data-handling requirement that a shared platform cannot satisfy.

The mistake is treating the migration as a port. It is not. The conversation design, the prompts and the tool definitions carry over, but the platform was silently handling scaling, retries, turn detection tuning and observability, and all of that now belongs to you. A migration that ignores this ships an agent that is cheaper per minute and worse to talk to.

I run migrations in a fixed order. First I measure what you have: per-turn latency, real cost per minute, and where calls actually drop. Then I rebuild on LiveKit or Pipecat and put the two side by side on your own recordings. Then we cut over gradually, by percentage of traffic, with the old platform still live behind it. Nobody finds out the new stack is worse from a customer. The full reasoning is in migrating off Vapi or Retell.

What you get

  • An audit of your current agent: latency, cost per minute, and drop-off points
  • A written build-versus-stay recommendation, including the case for not migrating
  • Rebuild on LiveKit or Pipecat with your prompts and tools carried across
  • Side-by-side comparison on your own call recordings before any cutover
  • Gradual traffic cutover with a rollback path that works
  • Handoff documentation your team can operate without me

How I work

Four stages, and you always know which one you are in

The same process whether the engagement runs two weeks or a year.

01

Understand the business

I ask product-level questions before quoting, so the work is scoped against what the business needs, not just the ticket as written.

02

Architecture in writing

You get the proposed architecture in writing before any code is committed. Disagreements happen on the document, where they are cheap.

03

Delivery in milestones

Work ships in milestones with regular updates, so you always know what has landed and what is next.

04

Documented handoff

Code is documented and handed off cleanly. Your future engineers should not have to reverse-engineer my decisions.

Direct Project Enquiry

Tell me what you are building

Share what you are building and where it is stuck. If a managed platform already solves it, I will say so. I review every enquiry personally and reply within about four hours.

  1. 1Send your project goal and the services you think you need.
  2. 2I review the context and whether I am the right fit.
  3. 3You get a direct reply with a practical next step.

International projects welcome

I work in English by email, video call or through Upwork, from GMT+7 with overlap hours for US and EU teams.

Read the Privacy Policy, Terms of Service and Cookie Policy.

Client project enquiries only

This form is for businesses and teams looking to hire. Sales pitches, recruitment messages, guest posts and link-building outreach are not reviewed.

Select Service *

In a hurry? Message me on WhatsApp at nguyentienm@gmail.com

Message me