Here's what Daniel's asking. Twilio and RingCentral both sell you telephony, and they have almost nothing in common. They started from the same premise — voice should leave the proprietary closet and become software — and then built things so different they barely compete. Twilio went full programmatic. A number is an object, a call is an event, everything is a composable primitive. RingCentral went the other way entirely — a finished product, sold by the seat, bought by an IT department, more appliance than API. Daniel's instinct is that all the legacy infrastructure Twilio abstracts away ought to collapse into the programmatic network eventually — that the mess is transitional. But he wants that instinct tested, not flattered, because the UCaaS world seems to be betting hard the other direction. He thinks the answer is in where Twilio's abstraction leaks, and his hunch is that the legacy refusing to dissolve isn't technical debt at all — it's jurisdictional. Emergency calling that has to know a physical address, number allocation rules that vary by country and demand local identity documents, anti-fraud registration regimes for messaging. None of it a bad interface waiting to be refactored. It's law wearing the costume of infrastructure. If that's right, the divergence isn't Twilio ahead and RingCentral behind — it's two different answers to which parts of the mess you're willing to own.
Let's start with the fork itself — what each company actually built — because the split happened earlier than most people realize and for reasons that are still driving both businesses.
Walk me through it.
Twilio launched in two thousand eight with an API-first model. The pitch was: telephony is just another web service. You POST to a URL, a phone rings. You write event handlers for call state changes the way you'd handle a webhook. Developers loved it because it turned a phone system into something they could reason about in code. RingCentral launched almost a decade earlier, in nineteen ninety-nine, as a hosted PBX. Same premise — get voice out of the closet — but they answered a completely different question. Twilio asked what a developer can build. RingCentral asked what a business can buy.
So the customer was different from day one.
Right. And the customer shapes the product in ways that compound. RingCentral sells to IT departments. IT departments buy outcomes — they want a phone system that works, with seats they can provision, features they can toggle, compliance baked in. They don't want primitives. They want the thing to ring when someone calls and they want to never think about it again. Twilio sells to developers who want to build the thing that rings. Those are different economic relationships. RingCentral charges per seat per month — predictable, recurring, easy for procurement. Twilio charges per API call, per minute, per message — variable, metered, ideal for someone who's building something where usage scales with their own product.
Which is why they barely compete. If you're an IT director buying a phone system for four hundred employees, you're not evaluating Twilio's Voice API. And if you're a startup building a notification system into your app, you're not comparing RingCentral's seat pricing.
And both of those are rational. The weird thing is that the industry talks about them as if they're on a spectrum — like RingCentral is just the less-evolved version and eventually everything converges on APIs. Daniel's instinct about the mess being transitional, that's the standard developer take, and I get why it's appealing. But the cloud PBX world has been growing for twenty-five years and it's not showing signs of collapsing into primitives. Something is holding it in place.
So let's get into the weeds of where Twilio's abstraction actually leaks. Because that's where Daniel thinks the answer is, and I think he's onto something.
The cleanest example is E911. Emergency calling. In the United States, when someone dials nine-one-one from a phone, the call has to route to the correct Public Safety Answering Point — the local dispatch center — and it has to transmit the caller's physical address. That's federal law. It's not a technical specification. It's a legal requirement that exists because people died when VoIP services couldn't tell emergency operators where the caller was.
And Twilio can't abstract that away.
It cannot. If you're a developer building on Twilio's Voice API and you provision a number, you must provide a physical address for E911 purposes. The API exposes a field for it. You have to fill it in. If your user moves, you have to update it. If you get it wrong and someone calls nine-one-one and the dispatcher goes to the wrong address, you are legally liable. Twilio can't hide that behind a clean interface because the law won't let them. The address isn't optional metadata — it's a jurisdictional fact.
And this isn't some edge case they haven't gotten around to refactoring yet.
It will never be refactored. The requirement exists because physical bodies exist in physical space and emergency services need to find them. No amount of API elegance changes that. The leak isn't in the code — it's in the world.
What about numbers themselves? Daniel mentioned number allocation rules.
That's an even deeper mess. Phone numbers are not globally fungible. Every country has its own numbering authority, its own allocation rules, its own identity verification requirements. In some countries you need a local business entity to get a number. In others you need a copy of a passport. In many places the number is tied to a physical address by regulation, not by technical necessity. When Twilio lets you provision a number programmatically, what's actually happening under the hood is a regulatory process that varies by jurisdiction. The API gives you a clean object — you call the Available Numbers endpoint, you get back a list, you buy one — but behind that simplicity is a patchwork of carrier agreements and compliance checks that Twilio's operations team has to manage country by country.
So the abstraction is real, but it's thin, and the thickness of it is all legal paperwork.
And it breaks in predictable places. Number porting is the classic. Daniel's actually run into this personally — trying to port a number to Twilio and discovering it's not a technical operation, it's a regulatory one. You can't just call an API and move a number. You need carrier cooperation, regulatory approval, sometimes a letter of authorization, and the rules are different in every country. Twilio can streamline the process, but they can't eliminate it because they don't control the numbering infrastructure — the incumbent carriers do, and the regulators mandate that they do.
The third one Daniel flagged was anti-fraud registration for messaging. The ten DLC thing.
Ten DLC — ten-digit long code. This is the regime for application-to-person messaging in the US. If you want to send text messages from an application — appointment reminders, two-factor codes, marketing — using a standard ten-digit phone number, you have to register your business with the carriers. You provide your tax ID, your business type, a description of your use case. The carriers run it through a vetting process. If you don't register, your messages get blocked or throttled.
And again, Twilio can't abstract this.
They built a registration flow into their console. They guide you through it. But they can't make it go away because it's not their requirement — it's the carriers', and the carriers are doing it because the FCC and the CTIA and a whole alphabet of regulatory bodies demanded it to combat spam and fraud. Twilio's API for sending a message is beautifully simple — one POST request — but before that request works at scale, you've spent days or weeks on compliance paperwork that has nothing to do with software.
So we've got three leaks, and none of them are bad interfaces. Emergency calling is law. Number allocation is law. Message registration is law. That's the pattern.
That's the pattern. And here's where it gets interesting. RingCentral deals with exactly the same requirements — E911, number porting, ten DLC — but the customer never sees them. RingCentral owns the mess internally. When you buy a seat, E911 address management is built into the admin panel. Number porting is handled by RingCentral's operations team. Compliance is part of the service. The customer gets a finished product with the regulatory complexity hidden behind a curtain.
So RingCentral's product isn't less sophisticated — it's a different strategy for the same constraint.
Yes. And this is the misconception I want to nail down. The industry narrative is that Twilio is the innovative one and RingCentral is the legacy holdover. But RingCentral is making a deliberate strategic choice. They're saying: the regulatory mess is permanent, our customers don't want to deal with it, so we'll absorb it into the product and charge for the privilege. Twilio is saying: the regulatory mess is permanent, but developers want control, so we'll expose it as cleanly as we can and let them manage it. Neither is wrong. They're just answering different questions for different buyers.
So if the mess is jurisdictional, what does that mean for the future of these two companies? Daniel's instinct was that the legacy ought to collapse into the programmatic network. But if the legacy is law, it doesn't collapse.
It doesn't. Law doesn't refactor. It accretes. The regulatory frameworks around telephony have been building for over a century — since the Kingsbury Commitment in nineteen thirteen, since the Communications Act of nineteen thirty-four. Every layer is a response to some actual harm that happened. E911 exists because someone died. Ten DLC exists because spam SMS became a plague. Number portability exists because regulators decided consumers should own their numbers. These aren't technical artifacts that a better protocol can eliminate. They're political settlements.
And political settlements change on political timelines, which is to say, glacially.
Right. So the vision of a fully programmatic network where everything is just API calls and events — that's not waiting for better technology. It's waiting for every telecommunications regulator on earth to agree that their local requirements don't matter anymore. That's not happening.
Which means the mess is permanent. And if the mess is permanent, the divergence between Twilio and RingCentral is structural, not transitional.
And it gets deeper. Both companies are actually moving further apart, not converging. Twilio has been building what they call the Super Network — a layer of abstraction that sits on top of carrier relationships worldwide, handling the interconnection so developers don't have to. They've added things like Elastic SIP trunking, which lets you connect existing phone systems to their network programmatically. But even the Super Network can't escape jurisdiction. It can smooth the edges, but it can't make E911 or number portability or ten DLC go away. The abstraction gets better, but the leaks are permanent.
And RingCentral?
RingCentral is pushing deeper into the finished-product direction. They're adding AI features — call transcription, sentiment analysis, meeting summaries. They're integrating with CRMs and productivity suites. They're building analytics dashboards. But the core model hasn't changed: it's a seat-based appliance, sold to IT, with the regulatory mess handled internally. They're not building toward primitives. They're building toward a more complete appliance.
So neither is converging on the other. Twilio isn't going to start selling seat-based phone systems to IT departments, and RingCentral isn't going to expose raw telephony primitives to developers.
Why would they? Their customers don't want that. The developer who loves Twilio's API would be horrified by RingCentral's admin console. The IT director who loves RingCentral's turnkey experience would be horrified by having to manage E911 addresses through an API. The split isn't a temporary market inefficiency — it's two stable equilibria.
Let me push on something. You said law doesn't refactor, it accretes. But law does change. Number portability didn't exist thirty years ago — now it's mandated in dozens of countries. E911 for VoIP didn't exist twenty years ago — now it's federal law. So the regulatory landscape isn't static. Could it shift in ways that make the programmatic network more viable?
It could shift in ways that make the mess different. I'm skeptical it makes the mess smaller. Every regulatory change I've seen in telecom adds requirements, it doesn't remove them. Number portability was a new mandate, not a deregulation. E911 was a new mandate. Ten DLC was a new mandate. The trend is toward more jurisdiction, not less.
Because every new capability creates a new harm, and every new harm creates a new regulation.
That's the cycle. Voice over IP enabled cheap calling, which enabled spam calling, which created STIR/SHAKEN — the call authentication framework. AI-generated voice will create new fraud vectors, which will create new authentication requirements. The programmatic network makes telephony more powerful and more dangerous at the same time, and the regulatory response is always to add another layer.
The future isn't one clean network. It's a patchwork of regulatory regimes that both companies have to navigate, and their divergence is a strategic choice about who bears the burden.
That's the reframe Daniel's getting at. Twilio and RingCentral aren't on a spectrum of progress. They're two answers to a permanent constraint. Twilio's answer is: we'll give developers the cleanest possible interface to the mess, and they can manage the parts that leak through. RingCentral's answer is: we'll manage the entire mess ourselves, and the customer pays us to never think about it.
Which means RingCentral's model has a kind of structural moat that the "Twilio is the future" narrative misses. If the mess is permanent, the business of hiding the mess is also permanent.
It's a good business. IT departments pay a premium for not having to think about E911 compliance. That premium is RingCentral's margin. Twilio's margin comes from a different place — it comes from volume, from being the programmable layer that thousands of applications build on. Both are viable. Neither is going to eat the other.
There's an irony here. The thing that makes Twilio feel so elegant — the API, the primitives, the composability — is also the thing that exposes the developer to the mess. The elegance is real, but it's an elegance that comes from showing you exactly where the complexity lives and handing you the tools to manage it. RingCentral's product is less elegant in the API sense, but more elegant in the "I don't have to care about this" sense.
Different definitions of elegance for different definitions of done. For a developer, done is "I can build anything." For an IT buyer, done is "I don't have to build anything."
Where does this leave Daniel's instinct? He wanted it tested, not flattered. I think we've tested it.
I think his instinct about the mess being jurisdictional is exactly right. That's the insight. Where I'd push back is on the idea that the mess is transitional. The jurisdictional mess isn't going anywhere. It might change shape — some countries might harmonize numbering rules, E911 might eventually move to IP-based location standards — but the underlying fact that telephony touches physical people in physical places with legal obligations will never go away. The programmatic network is a useful abstraction, but it's an abstraction over something that is fundamentally not software.
The divergence between Twilio and RingCentral isn't a temporary market inefficiency — it's the natural outcome of two companies seeing the same permanent constraint and making different bets about who should carry it.
Right. Twilio bets on the developer carrying it. RingCentral bets on carrying it themselves. Both bets are paying off.
Hilbert, you've been quiet. You've got something to say about this?
Hilbert: I did E911 compliance for a regional carrier in the early two thousands.
Wait, really?
Hilbert: Three years. Managed the database that mapped phone numbers to physical addresses for nine-one-one routing. We had a master list from the incumbent local exchange carrier, and it was wrong about fifteen percent of the time. People moved, numbers got reassigned, the updates lagged. We had a call come in from a woman having a heart attack. Address in the database was her old apartment. Paramedics went to the wrong building.
What happened?
Hilbert: She survived. Neighbor heard her and called from a cell phone. But the legal fallout took two years. Our carrier got fined, her family sued, the whole thing became a case study the FCC used to justify tighter rules. That's the thing about E911. It's not abstract. Somebody's database entry was out of date and a woman almost died. The regulation exists because the failure mode is not a five hundred error.
When we say the mess is jurisdictional, you're saying it's also physical. The copper, the switches, the databases that don't sync.
Hilbert: The law is built on top of the physical infrastructure. The physical infrastructure is ancient and fragile, and the law assumes it works a certain way. You can't reprogram it. There are places in this country where the E911 database is still updated by fax.
By fax.
Hilbert: I've received those faxes. You get a cover sheet and a spreadsheet printed from some county clerk's computer. You type the changes into your system by hand. That was two thousand four, but I know people still doing it.
The programmatic network is an abstraction over a system that, in places, still runs on fax machines.
Hilbert: The abstraction is real. Twilio's API works. But the thing underneath hasn't changed. The database is still the database.
That complicates Daniel's picture. It's not just law — it's law plus physical infrastructure plus institutional inertia. Three layers of permanence.
Hilbert: Here's the wrinkle, though. I've been to countries where the whole thing is already IP end to end. No copper, no legacy switches, fully digital telephony built after two thousand ten. And the legal frameworks there are still catching up. They have the programmatic network, but they don't have the regulatory clarity. So the mess is partly a lag — the law hasn't figured out what to do with a network that doesn't have physical addresses tied to copper pairs.
In some places the technology is ahead of the law, and in others the law is ahead of the technology.
Hilbert: Both are a mess. Just different messes.
Which means the mess isn't going away even if the technology modernizes. If you replace the copper with IP, you still need to know where the caller is. You still need to verify who owns the number. You still need to stop fraud. The requirements don't change — the implementation does.
Hilbert: I had a colleague who used to say: the phone network is the only system where the legal department has veto power over the engineering department. He wasn't wrong.
Hilbert, was this the same carrier where you did the compliance work, or was this a different job?
Hilbert: Same carrier. I started in billing, moved to compliance, left in two thousand six when they got acquired. Still have a box of E911 database printouts in my apartment. Can't bring myself to throw them out.
You have a box of emergency address records from twenty years ago.
Hilbert: It's a small box.
Do you know if the data is still relevant?
Hilbert: Some of it probably is. People don't move as often as you'd think.
I don't know what to do with that information.
Hilbert: Neither do I. That's why it's still in the box.
I think that's actually the perfect place to land. The mess is permanent, it lives in boxes in people's apartments, and neither Twilio nor RingCentral can make it disappear. They can only choose who has to open the box.
That choice — expose it or absorb it — is the entire shape of the industry. Thanks, Hilbert.
Hilbert: Yep.
This has been My Weird Prompts. Our producer is Hilbert Flumingtop. We'll be back soon.
