When to build messaging infrastructure, and when not to

The build-or-buy conversation in messaging usually compares a vendor's feature list with an engineering estimate, and reaches the wrong answer because both sides are estimating the wrong thing. Features are easy to copy and engineering estimates ignore operations. The useful question is different for each layer of the stack: what does it take to run this well, who is accountable when it fails, and can you leave if you need to? This piece walks through the layers, gives a worked example, and lists what to ask before signing.

Carrier relationships. Direct interconnect requires licences, commercial agreements and, in several markets, local presence. Building at this layer means becoming a telecoms company.

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

Registration at scale. Filing sender IDs and campaigns is feasible for one market, painful for five and unmanageable for thirty — see 10DLC registration and Gulf sender IDs for why.

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

The consent ledger. You are legally accountable for it and may have to produce evidence from it years later, after changing vendors. Consent that exists only in a vendor's console is accountability you have partly outsourced. If a platform stores it, insist on a complete, scheduled export.

Message history. What you sent, to whom, under which consent and template. You need it for disputes, audits and measurement.

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

Orchestration — what to send, to whom, when, and what to do about silence — is your business process. Two reasonable paths:

Renting is often right for smaller teams and standard journeys; building pays when your process is unusual or messaging is core to the product. Either way, the rules and the data should be exportable.

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

Buying converts a technical failure into a commercial relationship: a status page, a support contract and someone else's on-call rota. Building means the on-call rota is yours. For an organisation whose core competence is elsewhere, that transfer is usually worth more than the licence cost.

Two ways to get the seam wrong:

• Too late. Built after three vendors, when their status names, error codes and idea of "a message" are already throughout your application code.
• Too much. An abstraction with more configuration than the providers it wraps is a platform you built by accident and now maintain. The right one is boring, thin and slightly leaky — leaky enough that channel-specific features stay reachable.

A mid-size insurer sends policy documents, renewal reminders, claim updates and one-time codes in three countries.

• Bought: SMS and WhatsApp transport from two providers (one primary, one secondary for codes), including sender registration in each country.
• Rented: a journey tool for renewal campaigns, chosen partly because it exports journeys and event history.
• Owned: the consent ledger, the message log, and a send function with two adapters. Claim updates are triggered by the claims system directly through the send function, not through the journey tool.
• Result: when the secondary provider's route in one country degraded, codes were moved to the primary by changing one routing rule. No application code changed.

• Can I export consent records, templates, message history and journey definitions at any time, in a documented format?
• Who owns the sender IDs, numbers and registrations — can they move with me?
• Do your webhooks carry my own message IDs, so my log stays the source of truth?
• What is your incident process, and what do you commit to in writing when your service is the cause?

Next in this track: evaluating a CPaaS contract. For connecting several systems without forcing them into one, read federating without merging.