When to build messaging infrastructure, and when not to

The build-or-buy conversation in this category usually compares a vendor's feature list against an engineering estimate, and reliably reaches the wrong answer, because both sides are estimating the wrong thing.

Carrier relationships. Not a technical problem. Direct interconnect requires licences, commercial agreements and, in several markets, local presence. If you are considering building at this layer, you are considering becoming a telecoms company.

Deliverability reputation. Accumulated over years and attached to routes and sender identities. You cannot buy it and you cannot rush it.

Regulatory registration at scale. Feasible for one market. Painful for five. Unmanageable for thirty.

If any of these are the binding constraint, buy. There is no clever architecture that gets around them.

Orchestration. The logic of what to send, to whom, when, and what to do about silence is your business process. Vendors model it generically, which means their model is not yours, and the gap is where all the customisation cost lives.

The consent ledger. You are legally accountable for it and you must be able to produce evidence from it years later, possibly after switching vendors. Content that only exists in a vendor's console is content you have partly outsourced your accountability for.

The channel abstraction itself. A thin interface over one or more providers costs little and preserves the ability to move. Without it, migration means rewriting every call site.

Not "can we build this?" — almost always yes — but: what happens at 3am when it breaks?

Buying converts a technical failure into a commercial relationship: you have a status page, a support contract and someone else's on-call rota. Building means you have the on-call rota.

For an organisation whose core competence is elsewhere, that transfer is usually worth more than the licence costs.

Buy transport. Build orchestration and consent. Keep a thin abstraction between them.

This is not fence-sitting; it is a specific claim about where the leverage is. Transport is a commodity with real economies of scale and genuine regulatory barriers. Orchestration is your differentiation and nobody else's. The abstraction is cheap insurance that keeps the first decision reversible.

Building an abstraction so elaborate that it becomes the thing you maintain. If your channel interface has more configuration surface than the two providers it wraps, you have built a platform by accident and now you own it.

The right abstraction is boring, thin, and slightly leaky — leaky enough that channel-specific features remain reachable when you need them.

The expensive mistake is not building too much. It is building the transport abstraction after you have three vendors, because by then the vendor's data model is in your application code — their status names, their error codes, their idea of what a message is.

Write the send function on day one, when you have one vendor and it feels like pointless indirection. It is the cheapest insurance in this entire stack, and it is only cheap before you need it.

The question is never "build or buy". It is which layer, because the answer differs by layer and always has.

Buy interconnect and registration. Own consent, orchestration and the seam between your code and any vendor's. Decide each layer by what mediocrity costs there, not by what is cheaper to start. And write the send function before you think you need it.