Telecom & messaging

Telephony is one of those things that looks like a solved problem from the outside. There is an API. You POST a JSON body. A phone rings. How hard can it be.

Then you ship, and the answer arrives: your messages get filtered by a carrier you have never heard of, your calls connect but the audio is one-way for eight percent of users, your registration application sits in review for three weeks, and nobody at any of the three companies in the path will tell you which one is at fault.

I have built three products on this plumbing. DialAnyone does virtual numbers, SMS, and eSIM data. DMText does mass texting for enterprises. Citrus Mobile does pay-as-you-go travel data. Every one of them required going a layer deeper than the vendor quickstart, and every one of them taught me something I could not have learned from documentation. This page is about doing that same work inside your product.

What this actually covers

Voice. Inbound and outbound calling, IVR and call routing, call forwarding, recording, conferencing, and voice AI pipelines where a model sits in the middle of a live call. Programmable voice and SIP trunking both count. So does the unglamorous part: figuring out why one carrier's audio arrives fine and another's arrives clipped.

SMS and messaging. One-off transactional sends, two-way conversations, and campaign sends at volume. Includes the parts that decide whether messages arrive at all — registration, sender reputation, opt-out handling, retry and queueing behavior under load.

Virtual numbers. Provisioning, porting, and managing phone numbers across countries, with the per-country regulatory requirements that come with them. Some markets need a local address on file. Some need a business registration. Some will not sell you a number at all without a local entity.

eSIM and mobile data. Profile provisioning and delivery, activation flows, and per-megabyte billing infrastructure. This is a different world from voice and SMS, with different vendors and a different failure surface, and it is where most teams underestimate the work by the widest margin.

CPaaS architecture generally. Which provider, which product within that provider, how to keep the provider from becoming load-bearing in a way you cannot undo later.

The stack, and how to choose

The tools I reach for are Twilio, Telnyx, SIP, and direct carrier APIs. The interesting question is never "which is best" — it is which one matches the shape of your problem.

Twilio is the right default for most products. The documentation is the best in the category, the SDKs are mature, the community has already hit your bug and written about it, and the surface area is enormous — voice, messaging, verification, video, all under one account. If your product needs telephony but telephony is not your product, start here. You will move faster, and speed early is worth more than the margin you would save elsewhere.

Telnyx gets interesting when telephony is your product. It runs its own network rather than reselling, which shows up as more control over routing and, in my experience, better per-minute and per-message economics at volume. It is also friendlier to bring-your-own-SIP setups. The tradeoff is a smaller ecosystem: fewer Stack Overflow answers, fewer people who have already solved your exact problem. That trade is worth it when unit cost is a line item on your P&L rather than a rounding error. I wrote a longer comparison in Twilio vs. Telnyx for voice AI, which gets specific about the voice-agent case.

Raw SIP is for when you need the control and can carry the operational weight. Direct trunking, your own media handling, your own failover. It gives you the lowest floor on cost and latency and the highest floor on effort, because you now own registration, NAT traversal, codec negotiation, and being paged when a trunk goes down at 3am. Most teams should not start here. Some teams, at some volume, cannot afford not to end up here.

Direct carrier APIs come into play for eSIM, wholesale data, and country-specific number provisioning, where no CPaaS abstraction covers what you need. This is the least documented part of the field and the part where having done it before saves the most time.

The honest version of this advice: start on the provider that lets you ship, but build behind a thin internal interface of your own from day one. Not a heavy abstraction layer — just a boundary, so that "send a message" and "place a call" are your functions rather than a vendor's, called from thirty places in your codebase. Migrating providers later is then a week of work instead of a quarter of it. I have done that migration both ways and the difference between the two is entirely whether that boundary existed.

10DLC and A2P registration, which will eat a month if you let it

This deserves its own section because it is the single most common reason a US messaging launch slips, and almost nobody plans for it.

If you send application-to-person SMS over a US 10-digit long code, the carriers require you to register — a brand, tied to your legal entity and tax ID, and then a campaign describing what you send, who opted in, and how. Unregistered traffic gets filtered, throttled, or silently dropped, and "silently" is the word that hurts. Your logs say delivered. Your users say they got nothing.

Registration is not instant and it is not fully in your provider's control; it goes out to a registry and then to the carriers. Applications get rejected for reasons that read like riddles, and the fix is usually a wording change in your opt-in description or a sample message that matches what you will actually send. Toll-free numbers have their own separate verification process, with its own timeline. Short codes are a separate provisioning path again, more expensive and slower to stand up, and worth it only for genuinely high-volume consumer messaging.

The practical consequences for your roadmap:

• Start registration the week you decide to send SMS, not the week before launch. It is the long pole, and it is a paperwork pole, not an engineering one.
• Your opt-in flow has to genuinely exist and genuinely match what you wrote on the form. Registration reviewers check.
• Build opt-out handling before you build anything else in the messaging path. STOP has to work, immediately, permanently, and across every campaign that number sends.
• Deliverability is an ongoing property, not a launch-day one. Sending patterns, complaint rates, and content all move it. Watch delivery receipts as a metric with an alert on it, not as a log line nobody reads.

I have run this process end to end more than once. Most of the value I add here is not code — it is knowing which rejection reasons mean "rewrite one sentence" and which mean "your architecture assumed something the carriers will never allow."

eSIM, briefly, because it is genuinely different

If you are shipping mobile data rather than calls or texts, almost none of the above transfers. Provisioning goes through a subscription manager that hands the device an encrypted profile, usually via a QR code or an activation link. Getting that flow to feel simple to a traveler standing in an airport, on hotel wifi, before they have data, is a product problem as much as a technical one. Billing is metered per megabyte, which means usage reconciliation, mid-session cutoffs, and top-up flows all need to be right or your margins quietly disappear. Citrus Mobile is that problem, solved once already.

How the engagement works

Same as everything else I do: $1,000 a day, flat, no hourly billing and no retainer. Telecom work tends to split into two shapes.

The first is a build — voice, messaging, numbers, or eSIM as a real feature of your product, taken from nothing to production. That is a normal engagement measured in days on the calendar, and you will have something working in the first week.

The second is a rescue. Something is already shipped and something is wrong: messages are not arriving, calls drop, registration is stuck, or the provider bill grew four times faster than usage did. That is usually shorter and it is often the higher-leverage version, because the fix is frequently one architectural decision rather than a rewrite.

Either way you get the actual reasoning, including when the reasoning is "you do not need this yet." If a single Twilio API call and a webhook covers your case, I will tell you that on the call and you can go build it yourself, which is a cheaper outcome for you and a better use of a day for me. If you would rather have someone who has already been rejected by a 10DLC reviewer for reasons that made no sense, hit Book a call and tell me what you are building.