The developer newsletter engineers open is the one that reliably tells them something useful and never wastes their time. That is the whole game. Pick a format built around real value, either a tight changelog or a genuinely curated roundup, send it on a predictable cadence, write subject lines that describe rather than bait, and let people leave whenever they want. Do that and you build one of the few owned channels that survives every algorithm change and every ad-cost spike. Do the drip-sequence thing instead and you train your best-fit users to filter you into the archive forever.
Why bother with a newsletter when engineers hate marketing email?
Because they do not hate email. They hate being sold to. Those are different problems.
The same engineer who marks your nurture sequence as spam is subscribed to a handful of newsletters they read the moment they land. The difference is not the channel. It is whether the email respects their attention. A newsletter is the one marketing asset you own outright: no ranking change can bury it, no ad platform can price you out of it, and no feed algorithm decides who sees it. For a devtools company that is rare and worth protecting.
It also fits how this audience actually learns. Developers lean on dense, self-serve material over anything that feels like a pitch. Technical documentation is still the most-used learning resource among developers, cited by 67.8 percent of respondents (Stack Overflow 2025 Developer Survey). A newsletter that reads like a good doc, specific and skimmable, fits that habit. One that reads like a landing page fights it.
What should you actually send?
Pick one primary format and commit to it. Trying to be all three at once is how newsletters turn to mush. Here is the honest tradeoff.
| Format | What it is | Best when | Watch out for |
|---|---|---|---|
| Changelog / product | What shipped, what changed, what broke | You ship often and users need to keep up | Reads like release notes nobody asked for if there is no “why it matters” |
| Curated roundup | Handpicked links, tools, reading with your take | You have taste and a point of view in the space | Becomes a link dump the second you stop adding commentary |
| Deep-dive / original | One real piece per send, written by your team | You have SMEs and something to actually say | Slow to produce, easy to slip the schedule |
Most devtools companies should start with a changelog if they ship weekly, or a curated roundup if they do not yet have enough product news to fill a send. Deep-dives are the highest-value format and the hardest to sustain, so treat them as an occasional feature inside one of the other two rather than the whole thing.
Whatever you pick, the unit of value is “the reader learned or got something.” A changelog entry that just says “improved performance” is filler. “Query planner rewrite, 3x faster on joins over 10M rows, here is the flag” is a reason to open. The bar is the same one I wrote about in developer content engineers respect: specificity, working detail, no borrowed fluency.
How often should you send it?
On a cadence you can actually hold, and then never surprise people by breaking it. Consistency beats frequency every time.
Weekly works if you have weekly substance, which usually means a changelog or a roundup. Monthly is fine and honestly underrated for deep-dive formats, because it gives you time to make each send good. What kills newsletters is the ragged middle: three sends in one week, then silence for a month, then a guilty “we’re back!” email. That pattern teaches readers your newsletter is an afterthought.
Set the cadence at the level you can sustain on your worst month, not your best. If weekly means you are padding sends with nothing, drop to biweekly and make each one count. Nobody ever unsubscribed because a good newsletter came slightly less often.
What makes a subject line an engineer will open?
Describe the contents accurately and stop there. Engineers open subject lines that tell them exactly what is inside, and they have a finely tuned detector for the ones designed to manipulate.
“You won’t believe what we just shipped” gets deleted. “New: point-in-time restore for Postgres” gets opened by anyone who cares about that. The second one is not clever. It is just honest about what the reader gets by clicking. Curiosity gaps, fake urgency, “re:” prefixes on cold sends, and single-word teasers all read as tricks to this audience, and a trick that works once costs you the open the next ten times.
A few things that hold up with technical readers: lead with the actual thing (the feature, the topic, the number), keep it under roughly 60 characters so it does not truncate, skip the emoji unless it is genuinely part of your voice, and never write a subject line the body does not deliver on. Treat the subject line as an API contract. It promises what the payload contains.
How do you avoid drip-sequence sleaze?
Stop treating the newsletter as a funnel and start treating it as a publication. The sleaze is not the automation. It is the intent behind it.
The pattern engineers punish is the fake-personal automated sequence: the “quick question” that is clearly a robot, the “just following up” for the fourth time, the email written to look one-to-one when it is one-to-thousands. If you run onboarding automation, make it obviously helpful and obviously automated. A “here are the three docs new users get stuck on” email is welcome. A fake “hey, I noticed you signed up, got 15 minutes?” from a no-reply address is not.
Two rules keep you clean. First, every email should stand on its own value, whether it is send one or send fifty. If a message only exists to move someone to the next stage, it is a funnel step wearing a newsletter costume. Second, make leaving trivial. A visible one-click unsubscribe that actually works is not a leak in your funnel. It is what keeps your list full of people who want to be there, which is the only kind of list worth having.
What deliverability basics can’t you skip?
The unglamorous plumbing, because none of the above matters if your email lands in spam. You do not need to be a deliverability expert, but you cannot skip the fundamentals.
Authenticate your domain. SPF, DKIM, and DMARC are not optional anymore. Google and Yahoo now require bulk senders to authenticate with all three and to keep spam complaint rates below 0.3 percent, aiming for under 0.1 (Google Email sender guidelines). Your email platform handles most of the setup, but you have to add the DNS records and verify them. Send from a real subdomain like news.yourcompany.com so newsletter reputation stays separate from your transactional and sales mail.
Then protect the reputation you build. Only email people who opted in, remove hard bounces promptly, and watch your complaint rate like a metric that matters, because to the mailbox providers it is the metric that matters. One-click unsubscribe in the header, not just a buried link, is now expected. The through-line is simple: send wanted mail to people who asked for it, and the plumbing mostly takes care of itself.
How do you grow the list without buying garbage?
Ask people who are already getting value, and make the ask specific about what they will get. Honest list growth is slower and worth infinitely more than a bought one.
The lists that convert come from your own surfaces: a subscribe box on docs pages and blog posts, a checkbox during signup that is unchecked by default and honestly labeled, a link in your CLI output or release notes, a mention at the end of a genuinely good conference talk. The best-fit subscribers are people who already touched the product or the content and want more. Tell them exactly what they are signing up for and how often, so the expectation is set before they ever open a send.
What you do not do: buy lists, scrape emails, add people because they downloaded a whitepaper, or import your entire CRM. Purchased and scraped contacts wreck your deliverability through spam complaints and tank the engagement rates that mailbox providers use to decide whether you reach the inbox at all. A list of 500 people who asked to be there beats 50,000 who did not, both in results and in the reputation that determines whether the next send even arrives.
How do you know if it’s working?
Watch a small set of metrics that reflect whether people find it useful, and ignore the vanity numbers.
Open rate has gotten noisy since Apple Mail Privacy Protection started auto-loading images, so treat it as a rough directional signal, not gospel. The number that actually tells you something is click rate on the links you care about, because a click is a deliberate act. Track the unsubscribe rate per send too. A small steady trickle is healthy. A spike tells you a specific send missed, which is useful to know. And watch list growth net of unsubscribes over time, since a list that grows while engagement holds is the sign of a channel that is compounding.
Then close the loop to the business without turning the newsletter into a pitch. Tag subscribers and look at whether they convert, activate, or expand at a better rate than non-subscribers. In my experience they usually do, because the newsletter keeps your best-fit users warm and informed between the moments they are actively evaluating you. That is the quiet compounding value, and it does not show up in any single send’s open rate.
If you are trying to figure out which format fits your product and audience, or you have a list that is quietly dying, that is exactly the kind of thing I help devtools teams sort out. See how I work in the case studies, or tell me what you are building and we will figure out the channel worth owning.
