A communications platform of the kind Twilio operates bills its customers per message. Most of what it pays per message goes to carriers rather than to its own servers. The team commits to halving infrastructure cost per message this year. What does that buy, and what does it give up?

What is gained

Real money, and less of it than the target implies. If a platform's per-message cost of goods sold is roughly 80% carrier termination and regulatory fees and 20% its own compute, storage and delivery, then halving the infrastructure term removes 10% of cost of goods sold. At typical pass-through ratios that lands as on the order of one to two points of gross margin, which is worth having and is not the largest lever in the business.

There is a second gain that the target does not name: the instrumentation needed to measure infrastructure cost per message is the same instrumentation that makes the carrier term visible per route, per destination and per customer. That is usually the more valuable artefact.

What is paid

The quarters of engineering attention, and the opportunity cost of pointing them at the smaller term. The levers that move the pass-through term are architectural too; they simply live in a routing service rather than in a cluster. Least-cost routing per destination, carrier failover that considers price as well as deliverability, volume tiering that changes with committed traffic, and the ability to switch carrier per message rather than per region. A platform that cannot express those as data cannot act on 80% of its own cost.

The organisational cost is subtler: a target framed as "infrastructure cost per message" tells every engineer that the carrier term is somebody else's problem, and it stays that way.

When the cost becomes visible

At low volume, per-tenant floors and idle capacity make infrastructure the dominant term, unit cost falls steeply with growth, and the curve looks healthy. As volume grows the pass-through term takes over and unit cost flattens, usually well before the team expects it. A platform that instruments only its own infrastructure watches cost per message stop improving and has no telemetry that explains why. That is the moment the missing decomposition becomes expensive, because pricing and sales commitments have already been set against the earlier trend.

The decision rule

Split cost per unit into the controllable term and the pass-through term before setting any target, then optimise the largest controllable term. Pass-through is not a synonym for uncontrollable: it is controllable through contracts and routing, and the architecture decides whether you can exercise that control. Ask one question of the design: can a price change at a supplier be absorbed as configuration, or does it need a deployment?

How to keep the option to reverse

Keep the route table as data: destination, supplier, price, quality, effective date. Keep supplier-specific behaviour behind one adapter interface so adding or dropping a supplier is a contained change. Meter the supplier charge per message at the point the message is accepted for delivery, not from invoices, so you can reconcile and so you can see the effect of a routing change within a day rather than within a billing cycle.

When this is the wrong answer

For a product whose cost of goods sold is almost entirely its own compute, such as an inference API, a search backend or a video transcoding service, the split is trivial and the infrastructure target is exactly right. The decomposition still takes an afternoon and is worth doing once, because it tells you which kind of business you are in, and that answer changes as a company adds third-party components.