Developer marketing that actually works for a solo developer or a two-person team looks less like marketing and more like product work: docs worth sharing, code examples that run, a changelog that tells the truth. The campaigns and case-study PDFs that fill most "developer marketing" search results are built for a different budget and a different audience than the one this pillar's reader has.

What developers can actually smell

Ask anyone who's spent real time doing this what fails, and the list is short and specific. Lee Robinson, who spent five years on developer experience at Vercel working on Next.js and now works on ML at SpaceX (previously at Cursor), lays out the trust problem plainly: developers are skeptical of almost everything, they don't want to contact sales, jump on a call, or get junk emails, and they need to hear positive signals more than once before they'll try something new.

That trust is fragile in a specific way. Robinson's own bar for content:

• Be ruthless with editing
• Avoid buzzwords, acronyms, and vague explanations
• Don't publish anything you wouldn't share yourself
• Make sure every code example and every link actually works

A broken npm install in a getting-started guide tells a developer more about your product's quality bar than any amount of copy around it. That skepticism isn't static either: what the AI-coding-agent era has already changed about how developers themselves get evaluated is the same shift shaping what this audience now expects a product's own docs and workflow to demonstrate, not just claim.

The complication most developer-marketing advice skips

Here's the part most developer-marketing content, including Robinson's own essay, glosses over: who actually makes the purchase decision. In a Reddit thread discussing whether developer marketing is becoming its own category, a commenter who says they spent two years in developer marketing as a Head of Growth put it directly: "'developers' don't buy. The purchase decisions are not with the developers; they are with the CTO."

Two other commenters added real context. One framed the whole shift as product-led marketing, the product doing the selling for itself. Another drew a comparison to manufacturing and hardware, where the spec has always mattered more than "feel good" messaging, arguing dev tools are converging on that same model as the underlying layer becomes more foundational.

That's a genuine complication worth sitting with rather than a license to skip developers and go straight to procurement. It matters differently depending on how the sale actually happens.

A company with an enterprise sales motion needs the CTO's sign-off, regardless of how much a developer likes the product. A solo developer or two-person team selling a self-serve tool is usually in a different situation: the developer signs up, enters a card, and uses the product without anyone else in the loop. For that reader, "developers don't buy" doesn't hold, because there's no separate buyer to route around. Advice built for CTO-gated sales and advice for a bottom-up self-serve product point in different directions, even though most developer-marketing content treats them as one audience.

What actually works instead

Robinson's real point, stripped of the enterprise framing, holds up well for this reader: the product and its documentation are the marketing. Docs with real diagrams and working examples do more than a landing page ever will. Sharing how you actually built something, including the parts that were hard, earns more attention than a features list.

Concision matters more with this audience than with almost any other. Robinson's framing for a product-change announcement applies directly to a solo developer's release notes: put the bottom line up front, make it scannable, and address the reader's actual fear (will this break something, do I need to act, by when) instead of burying it under three paragraphs of preamble. A changelog entry that says exactly what changed and what to do about it earns more trust than a blog post announcing the same thing with none of the specifics.

Transparency about failure is the other real lever. Own a bug or a bad release publicly instead of quietly patching it and hoping nobody noticed. Developers already assume things break; what they're actually evaluating is whether you tell them the truth when it does.

What this looks like for one or two people

Robinson's examples (hackathons, meetups, dedicated developer relations headcount) assume a team this pillar's reader doesn't have. Scaled down to one or two people, the same principles turn into a much smaller, doable list: write the docs you'd actually want to read if you hit this error yourself, respond to the handful of real support threads you get like the person on the other end is watching closely (because they are), and post a real, specific changelog entry instead of a vague "improvements and bug fixes." None of that requires a content calendar or a marketing hire. It requires treating the people already using the product as the actual audience, the only one that's ever real at this stage.

The same instinct is behind why building in public works for this ICP specifically: the audience watching a solo developer's progress in public is disproportionately other developers, the same population this section is describing.

The actual verdict

Marketing to developers works when it stops trying to be marketing and starts being a plain, accurate account of the product. The campaigns built for a dedicated growth team and a CTO-gated sales cycle don't map cleanly onto a solo developer's actual situation, where the person using the product and the person deciding to pay for it are the same person.

Skip the case-study PDF. Fix the broken code example in the getting-started guide instead. That's the version of developer marketing a one- or two-person team can actually run, and it's the version this audience will actually trust.