· 6 min read
Where do you advertise developer tools without wasting money?
Developer tool advertising fails in most places, because the audience blocks ads and buys on docs. The channels that survive that, and what each one costs.
Developer tool advertising has to work on the least advertisable audience on the internet: people who run blockers by default, distrust marketing language on principle, and make purchase decisions by reading documentation. That eliminates most of the media landscape in one stroke. What is left is a short list, and the useful thing about a short list is that you can work through all of it. (Disclosure: this is published by BidSurvivor, which appears below with its wallet visible.)
The three places developers reliably see an advert
Documentation networks. EthicalAds grew out of Read the Docs and sells text-only placements on documentation pages: no tracking, no images, and — the part that matters — served in a context where a developer has a reason not to be blocking. Self-serve entry is in the low hundreds and the CPMs are published rather than quoted, which is rarer in this industry than it should be. We compared it against the obvious rival in Carbon Ads alternatives for indie makers.
Curated sponsor lines. Carbon Ads sells the same broad audience with a human deciding what runs. That is hundreds to low thousands a month, and it is the right purchase when you already know what your message should say. It is the wrong purchase for finding out.
Developer newsletters. JavaScript Weekly, Golang Weekly, Console, Pointer and a long tail of smaller letters sell one-off placements from roughly $100–500. The reader opened the email deliberately, which puts a sponsorship line closer to editorial than to display. Slow to book, high fit, and the format leaves nothing for a blocker to remove.
Notice what these three have in common. None of them intercepts attention. Each of them appears inside something a developer chose to open, which is the only condition under which this audience tolerates being sold to.
The channels that are not advertising at all
The uncomfortable part of any honest devtool media plan is that the four best channels do not accept money.
A public repository with a real README. For a great many tools this is the entire funnel. The README is the landing page, the issues are the support forum, and the star count is the social proof. Nothing you buy competes with it.
Hacker News. Unbuyable, unfakeable, and capable of sending more qualified traffic in a day than a quarter of paid placement. Post the thing, answer the questions honestly, do not campaign for votes.
Documentation search. Specific technical queries — an error string, a version-conditional edge case, a flag nobody documented — are unusually resistant to being answered above the results, because the answer is long and situational. That is one of the few remaining corners where good writing is also good distribution, which matters more now that general informational queries lose clicks to generated answers.
Other developers. Word of mouth is worth more here than in any category we know of, and it is the only channel that survives this audience's scepticism entirely intact. It cannot be bought and it can be earned, mostly by the product being good and the documentation being honest about its limits.
Every advertising dollar you spend competes with those four for the same attention, and it starts from behind on credibility. That is the arithmetic to hold in your head before buying anything.
The cheap experiment tier
Before spending a developer-audience CPM, there is one question worth settling for nothing: does your one-line description of the product make anybody click at all?
BidSurvivor — ours, so judge it accordingly. One board, two slots a day of twelve hours each, sold by open auction. The first brand into an empty slot pays $0 — no account, no card. Taking a slot somebody holds starts at $1.00, no bid can exceed $5,000, and every visitor starts with $100 of house credit before signing up for anything. Every brand's opens and click-throughs are published, so you can read what other placements did before you make one.
The specific and narrow use for a devtool is this: the audience is general web traffic, not developers, so it cannot tell you whether developers want your tool. It can tell you whether your sentence works on a cold reader, for nothing, in twelve hours. If a line cannot earn a click here, it will not earn one at Carbon's prices either — and if it can, you have a tested line to put in the placement you are about to pay for. There are worked examples of what separates the two in one-line pitch examples. The scale is honestly small, and the published numbers are how you check that rather than take our word for it.
A single newsletter placement. Once a line is tested, one $100–200 buy in a letter your users actually read beats three untested ones spread across networks.
What each channel is actually worth per visitor
Run the same division on every quote you receive and the comparison becomes boring, which is the goal.
Price divided by expected visitors gives cost per visitor. A $250 newsletter placement into a 12,000-reader list at a 1% click rate is 120 visitors, or roughly $2 a visitor, warm. A documentation-network buy at a $10 CPM and a 0.1% click rate is $10 a thousand impressions for one visitor, or about $10 a visitor, cold but contextual. A free slot is zero per visitor at a small and published volume.
Those numbers are illustrative — use your own click rates the moment you have any. The point of writing them down is that "which channel is cheaper" stops being a matter of opinion after the first purchase, and most people never do the division at all.
The order for a bootstrapped devtool
- README and documentation first, because they are free, compounding, and the actual channel.
- One honest launch post when there is something to show.
- A free slot to pressure-test the pitch line before anybody is paid for it.
- EthicalAds when there are a few hundred dollars for the audience that converts.
- Carbon and newsletter sponsorships once the funnel maths is known, not before.
The 2026-specific version of this argument — what the ad-blocking rate does to your reported CPM, and why verifiable claims outperform confident ones with this audience — is in developer tool marketing and the ad-blocking audience.
The theme underneath both: buy attention only where you can check what it did. Developers extend that courtesy to nobody, and neither should you.