When Hygraph neé GraphCMS emailed a 31% off Halloween discount to their subscribers, it was only reasonable to expect a modest uptick in sales. Shopify customers spent $9.3 billion on Black Friday 2023; surely, of the thousands subscribed to the GraphCMS newsletter, some would grab a discounted plan.
Cue the team’s shock when not only did no one use the discount code, but also over 200 people unsubscribed instantly from their emails. Even more concerning was their awareness that “devs are more likely to hit that spam button than you’d like to admit,” a fact born out in Hygraph’s data and numerous comments on Hacker News to that effect.
“This experience was my first, and hopefully biggest, mistake in email marketing to developers—treating them like any other user,” shared then-Head of Growth Ronak Ganatra of the debacle.
Some people want to know how they can save money on your product. Others want to know how your product can save them money, effort, and time. Knowing the difference between the two segments, letting users opt-in to the emails they want to receive, and sending the right emails to the right folks can be the difference between people excited to see your emails in their inbox, or sky-high unsubscribe and churn rates.
The rules for LII (Least Inbox Interruption)
“Space in my email inbox is space in my brain, and that's precious to me,” wrote Hacker News user NoraCodes in a thread about unsolicited emails to developers.
But it’s not that all emails are unwanted. Sometimes you want things to take up space in your brain. When X/Twitter restricted its GET following/followers endpoint to the Enterprise plan in June 2023 without letting anyone know in advance, developers were enraged. “Is this some kind of joke?,” asked one, rhetorically. “I’ve never seen anything like this before,” said another; “not sure what to tell clients.”
One suspects the 60+ developers who commented would have appreciated an email about the breaking change, ideally one sent far enough in advance to plan mitigation.
Those same developers, though, would likely be the first to unsubscribe from the platform’s default “Things you missed since you last logged into X” email. They might even be annoyed if X sent them a developer-focused email without their opting into it first, or emailed daily about API features even after opting into a list.
Least inbox interruption. That should be the goal. People are glad to be interrupted by an email when it warns them of or prevents a far larger interruption. They’re generally glad to receive messages that make them more productive, if they opted in. And they’re annoyed—or worse—when they are interrupted by irrelevant emails when it’s least convenient.
That leads to three rules for developer email (that, honestly, apply to everyone):
- Don’t auto-add people to email lists when they sign up for an app
- Let people opt into emails they want to receive
- Only send emails the receiver will appreciate
1. Don’t auto-add people to email lists when they sign up for an app
This one’s easy: First, do no harm.
The temptation’s high to opt everyone into everything. To leave the “subscribe to our emails” box checked when people sign up for your app. Don’t do that.
Even onboarding messages should be kept to a minimum, focused on the customer rather than your company’s success. “Inbound communication seems very heavily geared towards benefiting the company ... as opposed to being actually necessary or useful from the point of a customer,” wrote @tailspin2019 on Hacker News. “These thoroughly annoy me.”
Don’t auto-subscribe every signup to your email list. Only send onboarding emails in extreme moderation. Otherwise, there’s a chance developers will think the same as the replier to that comment, fairly or not: “That's what the spam button is for.”
Some emails you’ll have to send: Account verification, payment notices, and other critical communications. You may need to message about things that will affect users, including downtimes or breaking changes. And you’ll want to tell users about things you’re excited about, including new versions and promotions.
Applying the principle of least inbox interruption and audit messages to ensure they’re truly necessary. Email verification, yes. Welcome email, possibly not. Then sort messages if they’re most likely useful to an average user or a developer, if your product encompasses multiple audiences. Developers will want downtime notices, while they’re perhaps less likely to appreciate discounts. If someone signs up from your API page—or ever enables it on their account—opt them into your critical notices list (in Buttondown, you could do that by subscribing them with a tag). If they sign up from your standard pricing page and use more business-focused features, perhaps you’re safe sending feature and promotion details.
2. Let people opt into emails they want to receive
Then, for all other communications, let customers choose the emails they want to receive.
When you let people opt-in to certain segments, you’re also giving them the agency to opt-out of those segments without unsubscribing completely.
Take your blog, for instance. Some companies split out their developer and general interest content into separate blogs (or even, Microsoft MSDN-style, make blogs for each product and technology). Others keep content combined but separate it by tag.
Either way you organize content, use that as a way to split your newsletter into segments. Click a developer-focused Twilio blog post, and you’re invited to sign up for a “Developer Digest.” Business and general interest posts show a “Digital Dispatch” list subscription instead. They could subscribe to everything, or nothing, or something in-between. Their choice.
Give people a milder way to subscribe, even, so only those who truly want to be emailed sign up. Tailscale blog’s signup form says “Too much email?” underneath, with links to RSS and X in case you want to follow the blog but aren’t as keen about filling up your inbox.
The more focused the email list, the better. Uptime blogs, for example, are most commonly hosted on a 3rd party service, with a status.domain.com URL and an email list specifically for downtime alerts. That’s critical for reliability, so the core service going down doesn’t take the status page with it. But it’s also a helpful blueprint for thinking about developer-focused emails.
Have different newsletter segments for API changes and product features, perhaps. Include them in your settings, with clear differentiation between each email. Linear, for instance, lets you opt into changelog and DPA agreements, while auto-adding you to privacy and legal updates they’re required to send. Tailscale goes further, with separate email fields for each type of email, so developers can get security and configuration emails in their inbox, while sending account change notifications to a PM and billing emails to accounting automatically. Put the power in the customer’s hand.
With opt-in subscriptions, they can choose which emails they want to receive, and how they read them. Perhaps they’d rather sign up for your service with their primary email address, while following your blog with a personal email they check when they have time. Maybe they want a unique subset of your emails, instead of everything. They’re more likely to stay subscribed, and less likely to resent your messages, if they’ve customized subscriptions down to exactly what they want.
Then, if they unsubscribe, let them go. Don’t make them jump through loops, or keep them unsubscribed to segments they’re unaware they’re in. You’re more likely to win them back over time through your product, and more likely to anger them into churning entirely if you email after they subscribe.
3. Only send emails the receiver will appreciate
You’ve carefully built out email segments specifically for developers, let them opt into exactly what they want to receive, and made it easy to unsubscribe.
It’s a recipe for an engaged newsletter audience, if you can keep it.
“If a company that I'm interested in sends me an email once per month, then I generally don't mind it. I might even appreciate it,” wrote Steve Perkins in a discussion about emails. “Send it every two weeks, and you're training me to tune out. Send it weekly, and you've irritated me enough to have the motivation to unsubscribe.”
Everyone’s different, but Steve has a point. Even your fans only want to hear from you so often. Twilio promises a monthly email, no more. At Buttondown, we keep our email updates to the same timeframe. A more general-interest newsletter, or a paid subscription, might be something you want to read more often. SaaS and API updates, though, aren’t something you want to read every day. You could restrict your newsletter to once per month and inform subscribers of the schedule when they sign up. Or, you could use tags to segment your list by how often people want to hear from you.
Format matters too. GraphCMS found their ideal format after experimenting: New features listed in a nearly plain HTML email, with “no case studies, no sales CTAs, no upsells, no discounts, no fluff.” That led to consistent “40%+ open rates and 15%+ click rates,” along with substantive replies, something their more formatted emails never had. A plain Gmail email-style template might be best (like Buttondown’s default).
So does focus. You could send that monthly update email to everyone. Or, you could have your product send an API call to add a tag to newsletter subscribers if they use a feature—then skip reminding those people, since they’re already actively using it. They’ll never know you’re looking out for the space in their brain, but they’ll quietly appreciate it by staying subscribed.
Remain vigilant
After the hard work of segmenting developers into separate lists, writing emails focused on their needs, and making them opt-in only, you’ll still need to check your emails. Buttondown runs through a checklist of 62 validations every time before you send emails, checking for broken links, overly large images, missing attachments, and so on. You then need to build out tests for developer emails to ensure your messages strike the right balance of helpfulness without being overly salesy to prevent marketing creep in your emails.
One opt-in subscription and one email that delivers far more value than it requests at a time, and developers will start looking forward to seeing your name pop up in their inbox. They’ll know they can ramp up or down the emails they receive from you as they want, building trust in your company and emails alike.
Always remember: Very carefully subscribe people to your email lists. Very liberally unsubscribe them, too. That’s the formula for a happy—if smaller—email audience, developers and general public alike.