A four-person startup needs SMS phone verification at signup - roughly 20000 messages a month to US numbers. One engineer proposes sending directly through a carrier gateway rather than paying a provider such as Twilio. Which fact should decide it?
Show the full answer Hide the answer
The deciding property
The hard part of SMS is not sending; it is being allowed to send and being delivered. US carriers require business traffic on ordinary 10-digit numbers to be registered — a brand identity and a campaign describing the use case, with sample messages and proof of opt-in, filed through The Campaign Registry. Unregistered traffic is filtered or blocked outright, and enforcement tightened through 2024 and 2025.
Registration fees are small — on the order of tens of dollars one-off plus a few dollars a month per campaign in 2025 — but the approval lead time is days to weeks, and the work does not end at approval. Numbers accumulate reputation, opt-out keywords must be honoured, throughput per number is capped, and delivery receipts need interpreting when a carrier silently drops messages.
A provider absorbs all of it: the carrier relationships, the registration workflow, number reputation management, retries across routes, and the compliance surface. That is what is being bought, and none of it appears in a build estimate.
Why buying wins here
Verification is not a differentiator for this company. At 20,000 messages a month the entire spend is on the order of a few hundred dollars — comfortably less than one engineer-week per year out of a four-person team. The scarce resource is engineering attention, and the option being bought is the ability to ignore an entire regulatory surface.
Why the other options fail
- The per-message price. Direct routes are cheaper per message at large volume, and that is exactly why this reasoning misleads: at 20,000 a month the absolute difference is a rounding error, while the fixed cost of the relationship is not.
- The build estimate. "Two weeks" is the classic omission — it prices sending an HTTP request and omits registration, opt-out handling, delivery-receipt reconciliation, number rotation and the ongoing compliance changes. Build estimates fail on the lifetime of the thing, not on version one.
- The lock-in risk. This one is backwards. Verification is among the most portable capabilities there is: the interface is "send this code to this number", and swapping providers is a configuration change. Worrying about lock-in here spends judgement where there is no exposure.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| Messaging becomes the product | Direct or aggregator contracts | Margin on the core capability is worth owning |
| Volume reaches millions a month | Direct routes with a provider as fallback | Per-message cost now dominates the fixed cost |
| Regulated markets with local rules | Provider with in-country presence | Registration multiplies per country |
| Delivery becomes a competitive edge | Build routing over multiple providers | Route selection is the differentiator |
When this is the wrong answer
If the company already runs telecom infrastructure, the relationships exist and the calculation is different. The test is not build-versus-buy in the abstract; it is whether the capability is where the company wins. Buying is also wrong if a single provider outage would stop signups entirely and signups are revenue-critical — the answer then is two providers behind one interface, which is still buying.