The real unit economics of transactional email at scale

Transactional email looks cheap when you are sending 10,000 messages a month. It looks a lot less cheap at 10 million. Almost nobody checks what happens to their per-email cost as they scale, because vendors do not make that number easy to find.

Let's break it down.

The overage trap most vendors are running

Every major transactional provider runs the same playbook: a low sticker price to get you in the door, then an overage rate that kicks in once you pass your plan's included volume. That overage rate is where the real business happens, and it is almost never disclosed the way a unit cost should be.

Here is what that looks like across the market right now:

The SES row is worth unpacking, because it is the one people quote most and understand least. That famous $0.10 per 1,000 is the rate you pay with no subscription plan at all. The moment you take a plan, your entry rate goes up, not down:

To be fair to AWS, each plan does have genuine volume breaks: Essentials drops from $0.16 to $0.11 as you cross 100 million. That is a real discount. But look at what you are discounting from. Every plan starts above the a la carte rate, and you have to send over 100 million a month on Essentials before you get close to the $0.10 you could have had by not subscribing. The monthly fee is buying deliverability tooling and support, not cheaper email.

This is the part nobody says out loud: with most of these vendors, sending more email does not make each email meaningfully cheaper. It mostly moves you into a different flat-rate bucket. Your unit economics do not improve, they get relabeled.

Why bare metal changes the math

The overage model exists partly because most of these platforms run on rented cloud infrastructure, and they pass that markup through to you with their own margin on top.

The markup is real and it is bigger than people assume. One migration took a $7,370 a month cloud bill down to $460 a month by moving off managed infrastructure entirely. The best-documented case is 37signals, who published theirs on the way out: roughly $3.2 million a year came down to about $1.3 million after moving Basecamp and Hey onto their own hardware, against a one-time hardware spend of around $600,000. They project more than $10 million saved over five years.

Then add the bandwidth tax. AWS bills outbound data transfer at $0.12 per GB, which bare-metal providers routinely include at no charge. So the markup is not one big line item. It is compute, storage, and bandwidth, each marked up separately, all the way down.

When your infrastructure runs on bare metal instead of rented instances, that markup is simply not in your cost structure. And once it is gone, your pricing can reflect your actual marginal cost, which keeps dropping as volume goes up, because you are spreading fixed infrastructure costs across more sends rather than paying a per-unit tax on every one of them.

That is the whole difference. It is not a pricing philosophy. It is what happens when you remove a markup most of the industry has decided is a cost of doing business.

What this looks like in real numbers

At Anypost the rate falls as the included volume climbs, and it keeps falling well past the self-serve plans:

Two things about that table matter more than the numbers in it.

The first is that it exists. Every competitor at the top end of it says "contact sales." The whole ladder is published, out to a hundred million messages a month, with a 5 cent floor.

The second is what happens when you run past your allowance. Each tier prices its entire allowance at one flat rate, and overage bills at that same rate. The message after your allowance costs exactly what the message before it cost. There is no cliff at the boundary, because there is no separate overage rate for a cliff to live in.

That is the trap this post opened with, closed structurally rather than priced around. A vendor whose advertised rate and overage rate are the same number is making a different kind of promise than one whose overage rate is the number it declines to print.

Why this matters for your budget, not just your invoice

This is not an infrastructure nerd detail. It is a forecasting problem.

If you are modeling what your email spend looks like at 10x your current volume, and your vendor's overage rate is flat or rising, your email costs scale linearly or worse with your growth. That is a cost center that gets less efficient the more successful you are. Nobody budgets for that on purpose. They just do not notice until the invoice shows up.

A platform where marginal cost drops with volume does the opposite. It becomes a smaller percentage of your cost base the bigger you get.

What to actually do with this

Do not take a vendor's homepage price at face value. What works:

1. Model your cost at 10x your current volume, not today's. Most vendors look fine at your current send rate. The real test is what happens when you scale.
2. Ask for the overage rate in writing, not just the plan price. That is where the real cost lives, and for at least one major vendor it is not published at all.
3. Check whether the rate goes down or up as you change tiers. If a plan's entry rate is above the no-plan rate, you are buying features, not cheaper email. That may be worth it. Just know which one you are buying.
4. Ask what is underneath the platform. Rented cloud compute has a markup baked in that reaches you one way or another.

Email infrastructure is not glamorous, and pricing pages are designed to be skimmed rather than modeled. But if you are sending real volume, the difference between a vendor whose costs get worse at scale and one whose costs get better is not a rounding error. It is a line item that compounds every month you grow.

Anypost runs on bare metal, and the marginal cost per 1,000 drops as you scale instead of climbing. You can see the full rate card without talking to anyone.