Emit: Pay for Emails, Not Subscribers

Emit: Pay for Emails, Not Subscribers

I’ve launched a new thing: emit, a service that turns your blog’s RSS feed into an email newsletter. Point it at your feed, and when you publish, your subscribers get an email from your own domain. That part is table stakes. The reason I built it is the pricing.

The subscriber tax

Almost every newsletter platform prices on list size. Cross 1,000 subscribers, pay more. Cross 5,000, pay more again. Your bill is a function of how many people ever signed up, and it doesn’t matter whether you emailed them this month or not.

Think about what that means for a blog. A subscriber who signed up three years ago and quietly reads your monthly post costs you the same as one who signed up yesterday. If you take a two-month break from writing, you still pay full freight for the privilege of not sending anything. The pricing punishes exactly the behavior that makes independent blogs good: infrequent, unhurried publishing to a slowly compounding list.

Sending an email costs the platform a fraction of a cent. Storing a row in a subscribers table costs approximately nothing. Tiered pricing isn’t tracking cost, it’s tracking your success and billing you for it.

Metered instead

Emit charges $1.60 per thousand emails sent. That’s the entire pricing page. You buy prepaid credits (minimum top-up is $10, to keep Stripe’s fixed fee from eating small transactions), one credit is one email, and your balance goes down only when mail actually goes out.

Some consequences of this that I like:

  • A 5,000-subscriber blog publishing weekly costs about $32 a month. The same blog publishing monthly costs about $8.
  • Taking a break costs zero. Your list and your balance both just sit there.
  • There’s no free tier to outgrow and no cliff where your hobby suddenly costs $50 a month because subscriber 1,001 showed up.

The tradeoff is honesty in both directions: if you send a lot of email, you pay for a lot of email. There’s no unlimited plan to hide behind. I think that’s fair, and more importantly it means my incentives point the right way. I never profit from a bloated list you’re afraid to prune.

The boring features are the features

Under the pricing, emit is deliberately plain. It polls your RSS feed (or you can ping it on publish for instant sends). Every subscriber is double opt-in, no exceptions, because a list of people who confirmed twice is worth ten times a list of people you imported from a CSV of unclear provenance. You send from your own domain, with the DNS records surfaced in the dashboard until they verify. Opens and clicks show up per broadcast. Unsubscribes are one click, handled at the mail-client level with the proper headers.

It’s also API-first, in the literal sense that the API came before the dashboard. Everything the web UI does goes through the same public endpoints, documented in OpenAPI. If you’d rather curl than click, you’re the target market.

Since I started drafting this, the product has grown past plain RSS-to-email: a feed can now be a web page with no feed at all, or a plain-language description of what you want to follow, and a feed can be delivered to a Slack channel or a webhook instead of an inbox. That’s its own post. The pricing thesis below is unchanged, and the metered model is the reason the additions were possible without inventing a second plan.

Who this is for

If you run a newsletter as a business, with paid subscriptions and growth funnels and A/B tested subject lines, the big platforms will serve you better. Emit is for people with a blog and an RSS feed who want the writing to arrive in inboxes without adopting a second content management system. Write on your own site, publish, done.

The newsletter for this very blog runs on it, which will be the subject of the next post. Nothing has ever motivated me to fix bugs faster than being my own angriest customer.

Links: