ENGINEERING

Why We Switched from Twilio to Telnyx Mid-Sprint

Andres MuguiraFebruary 17, 20267 min read
TelnyxTwilioWebRTCVoIPMigration
← Back to Blog
Summarize with AI

Why Switch Providers During a Launch Sprint?

We had working Twilio calling. It was functional — you could click a button, a call would connect, and the audio quality was fine. But "functional" is not the same as "good," and we were about to launch on Product Hunt. If there was ever a time to get calling right, it was now.

Telnyx offered three things that mattered for a bootstrapped CRM. First, per-minute pricing that was roughly 40% lower than Twilio for domestic US calls. When you are building a product where every user might make dozens of calls per day, that cost difference compounds fast. Second, a cleaner WebRTC SDK that reduced our client-side code significantly — Telnyx's JavaScript SDK handles more of the connection lifecycle internally, which meant less state management on our end. Third, an API design that made advanced features like hold, recording, and speaker boost straightforward to implement without custom SIP headers or additional third-party services.

The decision was not purely technical. It was also about developer experience. Twilio's documentation is extensive but sprawling — finding the right approach for a specific use case often meant reading through five different guides. Telnyx's docs are more focused, with clearer examples for WebRTC-specific implementations. When you are a solo developer making decisions at 2 AM, clarity in documentation is worth more than breadth.

The Migration Scope

38 files changed in a single weekend. The scope was larger than we initially estimated, because telephony touches everything in a CRM that has built-in calling. The TwilioStore — our Pinia store managing call state — became TelnyxStore. Token generation moved to a new Supabase Edge Function called telnyx-token that provisions JWT credentials for the WebRTC SDK. Webhook handling was completely rewritten because Telnyx uses a different event format than Twilio, with different field names, different status codes, and a different approach to call lifecycle events.

Every call-related component needed updates: the dialer overlay, the in-call screen, call controls, the mobile keypad, incoming call notifications, and the call history log. We also had to update the number provisioning flow, because Telnyx's API for purchasing and configuring phone numbers has a different structure than Twilio's. The number porting process — moving existing phone numbers from Twilio to Telnyx — took the longest, not because of technical complexity but because number porting between carriers involves regulatory paperwork and verification steps that cannot be rushed.

Architecture: Browser WebRTC → Supabase Edge Functions → Telnyx

Implementation Details with Supabase Edge Functions

The calling architecture runs entirely through Supabase Edge Functions, which serve as the middleware between the browser and Telnyx's API. We have four Edge Functions dedicated to calling: telnyx-token for WebRTC credential provisioning, telnyx-call for initiating outbound calls, telnyx-webhook for processing call events, and telnyx-summarize for post-call AI summaries.

The token function generates a short-lived JWT that the browser uses to authenticate with Telnyx's WebRTC gateway. This token is scoped to the user's SIP connection and expires after 24 hours, which means we regenerate it on each app load rather than caching it. The webhook function processes real-time events from Telnyx — call.initiated, call.answered, call.hangup, call.recording.saved — and updates the call record in Supabase accordingly. Each event is idempotent, so if Telnyx sends a duplicate webhook (which happens occasionally), we do not create duplicate activity records.

The most interesting Edge Function is telnyx-summarize, which runs after a call ends if recording was enabled. It fetches the recording audio from Telnyx's storage, sends it through a transcription pipeline, and then uses Claude to generate a structured summary with key topics, action items, and sentiment analysis. That summary gets attached to the contact's activity timeline alongside the call duration and recording link. Sales reps get a complete call record without typing a single note.

What We Added During Migration

Since we were touching all the calling code anyway, we treated the migration as an opportunity to ship features that Telnyx made easy but Twilio would have required significant additional work:

The hold feature is a good example of the API quality difference. With Twilio, implementing hold required managing TwiML bins and updating the call's resource URL mid-call. With Telnyx, it is a single API call: PUT /v2/calls/{call_id}/actions/hold. The simplicity extends to the client side too — our hold button handler went from 40 lines of code to 8. Multiply that reduction across every feature, and you understand why the migration actually reduced our total codebase while adding functionality.

In-call screen with 6 control buttons including hold, record, and speaker boost

The In-Call Experience

The in-call screen features a dark background with the contact's avatar, name, company, and a live duration timer counting up from 00:00. Six control buttons arranged in a 2x3 grid: Speaker, Record, Mute, Hold, End, and Keypad. Each button provides visual feedback — active states glow with their respective colors, and when recording is active, a red REC badge with a pulsing dot appears at the top of the screen.

We spent considerable time on the call quality experience beyond just the UI. The WebRTC connection includes automatic echo cancellation, noise suppression, and automatic gain control — all handled by the browser's built-in WebRTC stack. Speaker Boost adds an additional software amplification layer on top of this, using an AudioContext gain node that amplifies the remote audio stream by 50% without clipping. This is especially useful on laptops with weak speakers or in noisy environments where you need the caller's voice to cut through ambient noise.

The mobile dialer experience mirrors the desktop version with touch-optimized controls. The T9-style keypad supports mid-call DTMF tones for navigating phone trees, and the contact matching system works in both directions — it identifies incoming callers against your CRM contacts and shows their full context before you even answer.

Cost Savings and Call Quality

After running both providers in parallel for a week during testing, the numbers were clear. Telnyx's per-minute rates for US domestic calls were approximately 40% lower than Twilio's, and the cost difference for international calls was even more significant. For a CRM where users might make 20-50 calls per day, that savings translates to real money over the course of a month — especially for small sales teams watching every dollar.

Call quality was comparable between the two providers in our testing. Both use the Opus codec for WebRTC audio, and both maintain Points of Presence across major US data centers. We did notice that Telnyx had slightly lower latency for calls to mobile numbers, likely due to their direct carrier interconnects rather than routing through intermediary networks. The difference was small — maybe 20-30ms — but perceptible in conversation flow.

Migrating telephony providers mid-sprint sounds insane. It worked because Telnyx's API was genuinely simpler — fewer lines of code for more functionality. Sometimes the best time to switch is when you are already rebuilding.

Lessons for Other Startups

If you are building a product with voice calling and considering Twilio because it is the default choice, take a serious look at Telnyx first. The API is cleaner, the pricing is better for high-volume use cases, and the WebRTC SDK requires less client-side scaffolding. Twilio has the larger ecosystem and more third-party integrations, so if you need advanced IVR flows or a marketplace of pre-built add-ons, it still wins there. But for straightforward browser-to-PSTN calling with recording and hold, Telnyx is the better developer experience.

The broader lesson is about timing. We could have stayed on Twilio and shipped a working product. But we recognized that the calling infrastructure was going to be foundational — every future feature would build on top of it. Investing a weekend in the migration saved us months of workarounds later. The best time to make a breaking infrastructure change is before you have users relying on the old system. We were lucky enough to catch that window, and the result is a calling stack we are genuinely proud of.

Try SalesSheet Free

No credit card required. Start selling smarter today.

Start Free Trial