Developer marketing for people who'd rather be shipping

Definition

What developer marketing is

Developer marketing is marketing a product to software developers. The audience is the hard part. Developers decide by trying the thing, reading the docs and asking someone they trust, and they skip anything shaped like an ad. So developer marketing is mostly showing your work in the places developers already read, and very little of it is persuasion.

Marketing for developers runs both directions. It's marketing aimed at developers, and it's also the marketing a developer has to do for the thing they built. This page covers both, because if you ship alone you're usually doing the second one to get the first one done.

The audience

How developers pick a tool

I don't have a survey for this and I'm not going to invent one. Here's what I do, and what I watched coworkers do for years in enterprise software. Someone mentions a tool. I open the docs before the homepage. I check whether the repo or the changelog moved recently. I try it on something small. If it works, I tell the next person who asks.

Every step there is something you can make true. Docs that answer the question. A changelog with a recent date on it. A way to try it without booking a call. None of those is a campaign, and all of them are marketing.

Where it happens

Developer marketing channels that work

Roughly in the order I'd set them up, cheapest first.

• Docs. The page most developers read before they decide. A quickstart that runs on the first try does more than any landing page I've written.
• A public changelog. Proof the thing is alive. A recent date tells a reader someone is still fixing bugs. The changelog format guide covers how to write one.
• Social posts about what shipped. X, Bluesky, Mastodon, LinkedIn. One change per post, written like a person, with the link.
• Show HN. Once, when people can actually try it. The Show HN rules want something people can run, with no signup wall, and they rule out landing pages and newsletters. Read them first. They're short.
• Reddit and forums. Answer the question the thread asked before you mention your tool. Mention it once. Getting downvoted for pitching is how most people learn this.
• Technical posts. How you built something, what broke, what you'd do differently. A post that teaches gets shared by people who will never buy anything, and that's fine, that's the reach.
• Talks and meetups. Slow and expensive in hours, and where trust compounds. This is where marketing turns into devrel.

Paid ads are missing from that list on purpose. They can work for a developer tool with budget and a clear buyer. I don't have either, and I'd rather not pretend to know the numbers.

The cheat

Shipping is the content

Every developer marketing guide says to create content. Here's the part they skip. If you ship every week, you already make content every week. It's sitting in your merged pull requests, written for reviewers instead of users. A PR that fixes a login loop on Safari is a post. A PR that adds an export button is a post and a changelog entry.

Swyx's essay Learn in Public makes the case for sharing what you learn as you go. Shipping in public is the same idea with a deploy attached. The hard part was never the writing. For me it was deciding, every single time, that this change was worth telling anyone about. I was always fine merging. Saying "I made this" out loud was the part I skipped.

So I built Merge & Tell to take that decision away from me. It reads a merged pull request, works out what changed for the people who use the product, and drafts the changelog entry and a post for each network I connect. Networks I trust it with publish on their own. The rest wait for me. I use it every day to promote Merge & Tell and my other projects, and the result is the updates page on this site.

If you'd rather do this by hand, the method still works. Keep a list of what merged this week, rewrite each line as what a user can now do, and post one a day. The product updates guide goes through it channel by channel.

Open source

Open source marketing

Marketing an open source project is developer marketing with less money and a pickier crowd. The audience can read your source, so anything you overstate gets checked. The good news is that the project itself is the best channel you have. A README that says what it does in one sentence, a quickstart, a CONTRIBUTING file, and release notes on every tag.

The TODO Group's guide to marketing open source projects is written for companies running bigger projects, and two of its points hold at any size. Publish your roadmap and your decisions where the community can see them. Skip slick, commercial-style marketing, because community audiences tend to reject it. Docs, meetups and case studies are its suggestions instead.

The release is the moment people pay attention, so put the most care there. The release notes template and the conventional commits guide cover the mechanics, and a tool like release-please will draft the notes from your commits.

If you charge money

Selling B2B SaaS to developers

Most SaaS marketing advice assumes one buyer who reads a landing page and books a demo. Developer tools usually have two people involved. The developer who tries it decides whether it works. Someone with a budget decides whether to pay. B2B SaaS marketing aimed at developers has to serve the first one without losing the second.

In practice that means a few unglamorous choices. Public pricing, so the developer can answer the budget question without a sales call. Public docs, not docs behind a login. A free way in that doesn't expire on day fourteen while they're still waiting on a code review. And a changelog the person with the budget can skim to see the product is moving.

I'm not going to tell you what to spend on ads or which agency to hire. I've never hired one, and the pages ranking for that question are mostly agencies recommending themselves.

Related

Developer marketing and devrel

Developer relations overlaps with developer marketing and isn't the same job. Marketing gets the word out. DevRel builds the relationship after that, through docs, sample code, community and talks, and carries what developers say back to the product team. At a small company the same person does both, and that person is usually the founder. More on that in what devrel is.

Honesty

What none of this fixes

Developer marketing can't fix a product nobody needs. It just gets you to that answer faster, which is worth something but doesn't feel like it. It also won't work in a burst. A month of posting followed by six months of silence reads worse than never starting, because the last date on your changelog is the first thing a careful developer checks. Cadence is the whole trick, and cadence is the part I needed a tool for.