How we built business calling on Telnyx (and why we didn't roll our own SBC)

Every "we built a phone system" blog post eventually arrives at the same question: did you roll your own SBC, or did you build on top of someone else's network? We didn't roll our own. This is the post explaining why that was the right call, and what it actually meant in practice.

The choice you're making

When you build voice, the spectrum looks roughly like this:

There are three ways to build a voice product. At one extreme, you operate everything yourself: your own session border controller, your own peering, your own fraud controls. In the middle, you run a cloud SBC on top of carrier trunks. At the other extreme, you build on a CPaaS like Telnyx and treat the carrier as a boring dependency. Each row shows what you actually operate, when it makes sense, and what you give up.

The mistake we see startups make is believing tier 1 makes them special. It doesn't. Customers don't care which kernel handled their RTP. They care whether the call connects, sounds clean, and routes to the right person. The tier-3 path gets you to all three faster.

Why Telnyx specifically

We tried the obvious three. The decision came down to four things that matter when you're multi-tenant from day one:

1. Programmable Voice that's actually programmable. Telnyx's Call Control gives us a TCP/WebSocket event stream and per-call commands we drive from a Node worker. Our flow engine is essentially a state machine reacting to those events. No proprietary scripting language to learn, no vendor-flavored XML.
2. Real-time billing data. Every call leg returns a CDR with carrier costs broken out. We mark those up per-tenant and bill in our own UI without reconciling against a bill that arrives 30 days later. Twilio buries this.
3. Number portability without drama. LOAs go through their portal, port-out completes get webhook'd back, and rejected ports come back with a rejection code we can map to plain English for the customer.
4. Wholesale-friendly pricing. When we resell, our agency partners pay close to wholesale carrier rates rather than a "communications tax." That's the difference between a 70% partner margin and a 35% one.

What we actually run

The runtime stack is easier to understand as two planes:

The runtime splits cleanly into two planes. The media plane is where audio actually flows: the browser, desk phone, or PSTN endpoint connects directly through Telnyx, and we never touch the audio. The control plane is where product logic lives: Telnyx's call-control events arrive at our worker through a queue, and Postgres holds tenant state and flow definitions. We're a control plane, not a data plane.

Media plane: Browser softphone, desk phone, or PSTN endpoint connects through Telnyx. The audio path stays off our servers.

Control plane: Telnyx emits call-control events, our worker turns those events into flow-engine transitions, and Postgres stores tenant state, flow definitions, and billing facts.

The worker is the interesting part. Every call event - call.initiated, call.answered, call.hangup, call.dtmf.received - lands on a queue and a state-machine processor decides what happens next based on the flow definition for that tenant. The flow editor in the UI compiles down to that same definition.

We deliberately do not keep call media on our infrastructure. RTP flows between Telnyx's network and the endpoint. We're a control plane, not a data plane. That means:

• No SBC to operate, no DDoS surface for SIP scanners.
• No PCI-style scope expansion when calls get recorded - recordings are Telnyx-stored, fetched on demand by our worker.
• We can add a region tomorrow by changing a config, not by deploying bare metal.

The hard parts the docs don't tell you

Three things ate more time than we expected:

Three production problems we had to design around. First, idempotency on call events: Telnyx redelivers events when the worker is slow, so every state transition is keyed by call control id and sequence. Second, multi-tenant DID hygiene: with thousands of numbers across hundreds of tenants, looking up which tenant a number belongs to has to be O of one on the hot path, so we cache it in the worker. Third, 10DLC throughput: SMS deliverability depends on campaign trust score, not raw API capacity, so we surface throughput limits in the dashboard.

Idempotency on call events. Telnyx will redeliver a call.answered event if the worker doesn't ACK in time. The naive thing - "respond to every event" - leads to double-processed states. We key every state transition by call_control_id + sequence. Cheap, prevents the worst class of bug.

Multi-tenant DID hygiene. When you have 200 tenants and 8,000 numbers, "this number rang, who does it belong to?" needs to be O(1) on the hot path. We cache the DID-to-tenant map in the worker process, hydrate on event, and reload it on number.assigned webhooks. Doing this in Postgres on the hot path was our first 99th-percentile latency issue.

10DLC throughput. SMS deliverability is a function of campaign trust score, not raw API capacity. A new campaign starts at low throughput and ramps as carriers see clean traffic. We surface throughput limits and historic delivery rates in the dashboard so customers don't blame the platform when really they need to age their campaign.

What rolling our own would have cost

We did the math. To replicate the Telnyx pieces we use - global PSTN peering, 10DLC submission, LRN dipping, carrier escalation contacts - the floor is roughly:

We did the math on rolling our own voice stack. The floor is roughly one senior voice engineer at three hundred thousand fully loaded, eight to fifteen thousand a month in transit and colocation for two regions, and six to nine months before you'd hit parity with what we shipped in week one on Telnyx. For any customer base under tens of millions of monthly minutes, that math never closes.

• 1 senior voice engineer ($300k+ fully loaded)
• ~$8-15k/month in transit + colo for two regions
• 6-9 months before parity with what we'd ship in week one on Telnyx

For a customer base under tens of millions of monthly minutes, that math never closes. Above that, you re-evaluate. We're nowhere near that inflection.

What we'd tell another team

If you're building a voice product and you don't have a voice team, the honest answer is: pick a CPaaS, build on top, treat the carrier as a boring dependency, and spend your engineering budget on the product your customers actually see - the softphone, the flow editor, the analytics, the white-label experience.

The hard problems in business telephony in 2026 aren't on the wire. They're in the UX.