Developer Marketing Does Not Exist with Adam DuVander
Adam DuVander once wrote a widely loved post on API authentication for Zapier. A developer tweeted that they loved everything about it — except the one sentence at the end mentioning Zapier's own platform. His answer to that kind of complaint: you can't please every developer, but giving readers a next step matters more than avoiding the risk of sounding like marketing.
Adam DuVander is founder of Every Developer and author of Developer Marketing Does Not Exist. He started his career as a developer, moved into tech journalism at ProgrammableWeb and Wired, then led developer marketing at Zapier and SendGrid.
This is the show's very first episode. We get into how a two- or three-person startup should prioritize content against everything else competing for their time, why articulating a strong, specific opinion matters more than being incrementally better at a best practice, why the person who ends up writing your first developer content probably isn't your best engineer, and how to judge whether a piece of content actually worked using developer intent rather than raw page views.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
For a startup with just two or three developers and barely anyone thinking about growth, how should they prioritize content against everything else they could be doing?
I haven't personally been at the two-to-three-person stage, but I have been at an early dev-focused company in a DevRel role, and there's a lot you can do even within that role beyond content — connecting with new signups, finding people already talking about problems your product solves. You can take what you learn from those other activities and turn it into content concepts that live beyond the moment — if you go to a developer meetup and talk to ten people, or present to fifty, how do you scale that conversation beyond the room? Content can amplify everything else you're doing. Like everything in a startup, it's not this-or-that, it's how you do it, and how you make producing content as low a barrier for yourself as possible, since it takes a while before you see the big organic-growth effects.
So the best content comes out of those real interactions rather than being planned separately?
Yes — taking the real problems you notice talking to real people and turning that into content is the best type of content at any stage, but especially early on. You started your company for a reason, solving certain problems well, so zeroing in on those problems and explaining them in a way that resonates with a developer, whether they meet you in person or find it through a search result or Hacker News, is the goal.
Where should a startup actually start with that?
We often ask clients of any stage: what does your company believe that competitors don't? Zero in on the differentiator — you probably didn't start this company to be the sixth version of some existing dev tool, you started it because something is wrong with the other five. Start with that problem-level thinking rather than starting from the product or the company itself. It's fine to eventually publish 'why we're building devtool X' for people who already know you, but getting at the actual problem devtool X solves, and why you're solving it differently, is more likely to reach someone who hasn't heard of you yet. To stand out as a small startup, you need to share opinions, and they probably need to differ from what everyone else is doing — saying you're 5% better at some best practice won't get attention. You may need to be a little provocative, but the most important thing is being real to the point of view you actually founded the company on.
That reminds me of Fly.io — one of the founders also created the Phoenix framework, and I read a piece about how they started it because they felt Ruby on Rails wasn't good for messaging and real-time communication.
Exactly — real-time communication apps in Ruby, or whatever the specific gap is, digging into that missing piece is exactly why Phoenix was created in the first place.
So one of the first things a startup should focus on is really solidifying and articulating that opinion?
Right, and I'd emphasize articulating it, because the opinion already exists by the time they've started the company — at least a first hypothesis of what that opinion is.
Once they've figured out what to say, how do they get the actual developers building the product to write great content, given how hard it already is to keep up with feature work?
In describing this podcast's audience, you mentioned there's probably someone who isn't full-time on code — that person, even if writing is just one of their miscellaneous responsibilities, is probably the one to write it. I'd start with whoever has the most natural interest in writing; you'll see the spark happen and their fingers go to the keyboard. Trying to force an engineer to write when they're not naturally motivated to rarely works well — I've seen companies say 'let's all write one post a month, there's four of us, so we'll get one a week,' but the same traits that make an engineer great at their job can make them take an entire week to write and polish a single post. I'd caution against everyone contributing full written pieces; the knowledge they have can sometimes be captured another way and written up by someone else. Realistically, the initial posts will likely be written by whoever is already doing marketing and sales activities — probably you, if you're listening to this podcast — unless someone on the team has that natural inclination, in which case, absolutely encourage it.
Once they've overcome the challenge of writing something, how should they think about distributing it?
We jumped ahead to a specific type of content — blog posts, what marketers might call top-of-funnel content. But there are other content types to prioritize, like documentation, which should obviously be product-focused and live in its own section explaining how something works and some contextual why. It's fine for documentation to focus on your product — that earlier advice about not being product-focused applies to the blog-style content. That still makes the most sense to publish on your own site first, since it takes time to build search traffic, so you're planting seeds for future growth and helping your site's broader SEO. That doesn't stop you from also publishing elsewhere — Dev.to, Hashnode, topic-specific blogs — and most of those let you set a canonical URL back to your own site, so republishing isn't an SEO concern if it's set up correctly. Beyond republishing, share it in communities — Hacker News, relevant subreddits, Slack channels and Discords for a scrappy startup — in an authentic, non-promotional way. If you've written the content right, focused on a problem rather than 'rah rah, here's why we built this company,' it should already read that way, since problems are what actually engage developers' minds, and comment sections exist so people can share their own take. Just watch out for posting at high volume in the same places, which reads as promotional and risks getting you banned. Be a good community member, and for the first few posts, don't be bashful about asking friends and colleagues to share it.
Does that bashfulness maybe say something about the content itself?
You might feel some bashfulness no matter what, since putting yourself and your new company out in front of people takes practice — all the more reason to do it repeatedly and get the reps in. But if you're really reluctant to ask someone you know well to share something, it might be worth asking yourself whether the content is genuinely helpful, or whether there's too much promotion in it.
Once content is out there, how do you know if it was actually a good piece?
There are different levels to gauge that. The first is a gut check, similar to when you talk to developers about your tool — do you get the glazed-eyes look, or do they go 'oh, that's interesting'? Long before I joined SendGrid, as a developer myself, I had to implement transactional email without SendGrid existing yet — emails would go to spam, and solving it meant navigating a maze of allowlists. When I first saw SendGrid as a Techstars company, I instantly got it: everyone talks about email newsletters, but what about the one email — a receipt, a confirmation — that absolutely has to land? That instant recognition is the same gut check you get sharing a piece of content and immediately sensing you've hit a nerve. You get better at spotting that with repetition, even before publishing, which helps you prioritize. You also need to make sure the content, while not overtly about your product, is still connected to it in some way. The classic mistake is chasing raw page views — programmer jokes get a lot of search volume, for instance, but I can't think of many dev tools that can meaningfully connect that traffic back to their product. In SEO people talk about search intent; I'd apply the same idea as 'developer intent' — what's the intent behind someone reading this, and what would they logically do next? If your content is genuinely focused on a real problem with high developer intent, then even small page-view numbers mean something. Early on you might be talking about a hundred views rather than thousands, but if it's the right hundred, they're much more likely to take the next step — trying your product, or signing up to hear about a beta. I think about developer experience as having a first 'hello world' moment and then a first real success, and you can trace that funnel well beyond the content itself, down to whether someone's actually using the tool — but the content stage should always end with an obvious next step. If you've been genuinely helpful and problem-focused throughout the piece, most developers will forgive you for mentioning, at the end, that you happen to have a tool that helps with the exact problem you just described. Some won't forgive you — I wrote a long post for Zapier on API authentication that a developer tweeted glowing praise about, 'except for the marketing spiel' at the end, where I'd mentioned that Zapier connects to APIs and APIs need authentication. As a writer I take pride in not getting sniffed out as a marketer, so that stung a little, but you'll always have people who love the rest of the post and still can't help but flag that. I think giving readers a next step matters more than avoiding the risk that one developer won't like you mentioning your product.
So it comes down to page views and engagement, filtered through developer intent, and then trying to capture that intent somehow?
Right — we might avoid the word 'conversion,' but yes, some way of getting them to take that next step.