Per-subscriber vs per-send email pricing, worked out

Almost every email tool meters one of two things: how many people are on your list, or how many emails you send them. Which is cheaper is not a matter of opinion. You can work it out with one division.

I build an email tool that bills by sends, so I am not neutral here. That is exactly why the arithmetic below is worth doing on your own numbers instead of taking anyone's word for it, mine included.

The one number that decides it

Take the number of emails you send in a typical month and divide it by the number of people on your list. Call it send intensity.

20,000 subscribers, two campaigns a month to all of them: 40,000 sends over 20,000 subscribers, an intensity of 2. The same list with one campaign every other month: 10,000 over 20,000, an intensity of 0.5.

Low intensity favours a per-send meter, because you pay for the small number rather than the large one. High intensity favours a per-subscriber meter, because the subscriber count is fixed no matter how often you hit send. Everything else is detail.

Subscribers	Cadence	Sends / month	Intensity	Better meter
20,000	Every other month	10,000	0.5	Per send
20,000	Monthly	20,000	1.0	Roughly level
20,000	Weekly	80,000	4.0	Per subscriber
2,000	Daily	60,000	30.0	Per subscriber, clearly

Why software teams usually land below 1

A list compounds. Every launch, every mention, every month of organic signups adds people, and nothing removes them except unsubscribes and bounces.

Sending does not work like that. For a product team, sending is gated by having something worth announcing, which is gated by engineering time. You do not ship twice as often because your list doubled. So the numerator stays roughly flat while the denominator climbs, and intensity falls month after month.

That is why per-subscriber pricing feels increasingly unfair to a growing software company and feels fine to a daily newsletter. The newsletter's intensity is pinned high by its format. The software company's drifts down by default.

The quiet cost of a per-contact meter

When contacts cost money, every decision about your list becomes partly a billing decision:

• Do we put trial signups on the list, or only paying customers?
• Should we delete the contacts who have not opened anything in a year?
• Do we keep the churned accounts, in case they come back?
• Can we afford to keep the people who unsubscribed, as a record that they did?

Each of those has a correct answer from your business's point of view and a different answer from your invoice's. Keeping no record of who opted out is actively risky: if you cannot see that someone unsubscribed in 2024, nothing stops a fresh import mailing them in 2026.

When subscribers are free, all four questions collapse into one answer: keep the accurate list.

What to check beyond the meter

Three mechanics change the real cost more than the rate does:

• Overage behaviour. Does going over your allowance charge you automatically, throttle you, or stop sending? An automatic overage on a per-send plan can turn a mistake into an invoice, which is why a hard cap is worth having.
• Rollover. Most allowances reset monthly. An occasional sender should size the plan to the month they actually send, not to their annual average.
• Whether transactional counts. If your app sends password resets and receipts, running them through the same allowance is usually cheaper than a second vendor, but only if the allowance is sized for both. Add them to the numerator before you pick a tier.

Where I land

I built day3 on the per-send side of this: unlimited subscribers on every plan, transactional email through the API from the same allowance, and sending pauses at the cap instead of billing past it. Plans run from $1/mo for 1,000 emails to $220/mo for 1,000,000.

The honest summary: if your intensity is comfortably below 1 and your list is growing, a per-send tool is built for you. If you send a daily letter to a few thousand people, it is not, and a per-subscriber tool will serve you better.

What is your intensity? I am curious where most dev.to readers land.