One tenant decides whether everyone else's mail arrives.

In most multi-tenant products a badly behaved customer harms themselves. In a sending platform they harm everybody. Receiving systems score the infrastructure, not the account — so one tenant mailing a bought list degrades delivery for every other tenant on the same paths, and the victims have no idea why their numbers moved.

That single fact reshapes the product. Permission to send cannot be a side effect of signing up; it has to be a gate with a human behind it. Accounts start unapproved, a balance or credit requirement discourages casual abuse, a public identity has to be established before the first send, and there is a queue where somebody looks.

Every one of those feels like friction when you are trying to grow, and every one of them is cheaper than the alternative. Once shared infrastructure is damaged, recovery takes months and there is nothing to ship that fixes it.

An email client is a rendering environment you have no control over, that strips scripts, rewrites styles, blocks images by default, and behaves differently across dozens of implementations. Anything that must be correct cannot be code that runs there.

So the things that have to be right get rendered on the server and delivered as an image. Native ad formats in one of my products are composed server-side and served as a picture, because a picture is the only thing every client agrees about. Content that has to be current — a countdown, a price, a live number — is resolved at the moment of opening rather than the moment of sending, which is a different pipeline with different caching and different failure modes.

The general principle transfers well beyond email: when the display environment is hostile and unversioned, move the correctness to where you control it and ship the result rather than the instructions.

Open and click tracking looks trivial and is not. Security scanners fetch the tracking pixel and every link within milliseconds of delivery, so naive counting records a burst of engagement that no human performed. A link rewriter that touches every href will happily rewrite the stylesheet in the document head and record rendering as a click.

Both of those were live in a product of mine. One report showed an open rate above three hundred percent, which is at least an obvious symptom. The dangerous version is the one that inflates by forty percent and looks plausible.

Uniqueness has to be an atomic claim rather than a check followed by an insert, exclusions have to cover the assets a client fetches on its own behalf, and — the part nobody enjoys — when you fix it you have to recount and tell customers their numbers have gone down.

A campaign is queued, then delivered over minutes or hours, against a balance that is decremented as it goes. Every interesting bug in a sending platform lives in that gap.

The rules that survived contact with production: claim the ledger row before doing the work rather than after, so a crash leaves a recoverable state instead of a silent discrepancy. Derive balances from rows rather than holding a mutable number. And at zero, pause rather than drop — a customer whose sending stops can top up, while a customer whose messages vanished has lost something they cannot get back.

None of this is exotic. All of it is the difference between a platform an operator trusts and one they reconcile by hand every month.

Running five hundred campaigns a month is not five hundred times the effort of running one, but only if somebody builds the tooling for it. Scheduling, per-destination reporting, complaint projection, and a way of ranking which accounts need attention this week — none of it is customer-facing and all of it decides whether the operation needs three people or thirty.

The default sequencing is to build the customer-facing product and add operator tooling once the support load forces it. That order is expensive in a way that never appears on a roadmap, because by then the operation has already grown the headcount that the missing tooling required. I built that layer at an agency before building the platform it later supported, which is the order I would choose again — you learn what an operator actually does at two in the afternoon on a bad day, and it is never what the roadmap assumes.

The lasting version of this lesson: if your admin surface is an afterthought, your support cost is the product's real price, and it is paid every month forever.