Developer marketing is the practice of earning adoption from people who evaluate a product by running it rather than by reading about it. For AI and data tooling specifically, the hardest part is not building the thing. It is being noticed at all.
We pulled every Show HN post submitted to Hacker News in the 12 months to August 2026: 40,437 launches. The median score was 2 points. Among the 14,658 posts whose titles referenced AI, LLMs, agents, models, or machine learning, 82.5% finished below 5 points and 62.5% received zero comments. Exactly 182 of those 14,658 AI launches, or 1.24%, cleared 100 points.
That distribution is the reason developer marketing exists as a discipline. This article covers what the data shows about launch outcomes, why technical audiences behave differently from other buyers, the mechanics that actually produce adoption for AI and data tools, and how to measure any of it.
What developer marketing is, and what it is not
Developer marketing, sometimes written as B2D or business-to-developer marketing, targets an audience with three properties that break conventional marketing assumptions. They can verify claims directly. They are usually not the person holding the budget. And they treat promotional language as evidence against the product.
It is not a rebranding of B2B demand generation with technical vocabulary. The mechanism is different. In conventional B2B, marketing creates belief and sales converts it. In developer marketing, the product creates belief during a self-service trial and marketing’s job is to get a qualified person to that trial with correct expectations.
Why this matters more for AI and data tools than for other software
Three conditions make this category unusually hard.
Category saturation. GitHub’s Octoverse 2025 report recorded more than 1.1 million public repositories using an LLM SDK, with 693,867 of those created in the trailing 12 months, a 178% year-on-year increase. The supply of AI tooling is expanding faster than any individual developer’s capacity to evaluate it.
Falling trust despite rising adoption. Stack Overflow’s 2025 Developer Survey found 84% of respondents using or planning to use AI tools, up from 76% the year before, while positive sentiment fell from above 70% in 2023 and 2024 to 60%. In the same survey, 46% said they actively distrust the accuracy of AI tool output against 33% who trust it, and only 3% reported high trust. Among the most experienced developers the high-trust figure was 2.6% and the high-distrust figure was 20%.
Claims are cheap and verification is expensive. Any AI product can claim a benchmark result. Reproducing that claim costs the reader an afternoon. When verification is expensive, readers substitute heuristics, and the dominant heuristic is scepticism.
Adoption rising while trust falls is the defining condition of this market. It means the marginal buyer is more willing to try your tool and less willing to believe you about it.
What does the launch data actually show?
Most launch advice is written by people describing successful launches. Selection bias makes that advice close to useless, because the population of failed launches is invisible. Hacker News is one of the few venues where the full population is public.
Method: We retrieved every post tagged show_hn submitted in the preceding 365 days using the public Hacker News Search API, requesting in seven-day windows to defeat the 1,000-result pagination limit and deduplicating by object ID. That produced 40,437 unique launches. We then flagged the subset whose titles matched AI, LLM, GPT, agent, model, RAG, MCP, embedding, inference, fine-tuning, or machine learning terms: 14,658 posts.
The full distribution
| Outcome threshold | All Show HN (n=40,437) | AI/ML subset (n=14,658) |
| Median score | 2 points | 2 points |
| Under 5 points | 81.8% | 82.5% |
| Under 10 points | 91.4% | 92.5% |
| Under 50 points | 96.9% | 97.7% |
| Reached 100+ points | 1.76% | 1.24% |
| Zero comments | 61.9% | 62.5% |
| One comment or fewer | 78.8% | 80.0% |
Two readings matter here.
First, the AI subset performed slightly worse than the general population on every threshold. Being in the most-discussed category in software is a disadvantage at the point of launch, not an advantage, because the audience has already seen forty similar submissions that week.
Second, the failure mode is silence rather than criticism. Nearly two thirds of AI launches received no comment at all. A launch that gets torn apart in the comments has succeeded at the hard part, which is attention. A launch with zero comments never entered the market.
What the top of the distribution has in common
The highest-scoring AI launches in the sample were not general-purpose platforms. Reading the top entries, the pattern is a specific, verifiable, small claim: a 26M-parameter model distilled for tool calling, a sub-500ms latency voice agent built from scratch, a text-to-speech model under 25MB, a 125M model doing on-device piano autocomplete, guardrails moving an 8B model from 53% to 99% on agentic tasks.
Every one of those is a number a reader can check. None of them is a category claim. The launches that worked said “here is a measured result on a narrow problem,” and the launches that vanished said “here is a platform for X.”
Why do good AI tools fail to get adopted?
Four mechanisms explain most of the gap between a working product and an adopted one. None of them are solved by better copywriting.
The claim cannot be verified in the first five minutes
A developer arriving from a link gives the project a short window before deciding it is not worth the context switch. If the fastest path to a verifiable result requires an account, an API key, a cloud provider, and a config file, the evaluation ends before it starts. The strongest AI launches in our sample all had a demonstrable result available immediately, often a hosted demo or a single command.
The positioning is a category rather than a problem
“An agent framework” describes a shelf, not a purchase. Developers search for the failure they are currently experiencing, in the words they would use in an incident channel. Positioning that names the failure gets found; positioning that names the category competes against every other entry in it.
The benchmark is unfalsifiable
Publishing a headline number without the evaluation set, the baseline, the hardware, and the failure cases reads to a technical audience as a marketing claim. Given that only 3% of developers report high trust in AI output, an unfalsifiable benchmark actively lowers credibility rather than raising it. Publishing the conditions under which your tool loses is worth more than publishing the conditions under which it wins.
Distribution is treated as a single event
A launch is one day. Adoption is the compounding result of documentation that ranks an active repository, and practitioners referencing the tool in threads where the problem is being discussed. Teams that treat the launch as the strategy have one day of traffic and no second act. This is the specific failure that a structured developer marketing program exists to prevent: replacing a single launch moment with a continuous presence in the places where evaluation actually happens.
What actually drives adoption for AI and data tools?
The sequence below is ordered deliberately. Running step four before step one produces traffic into an experience that cannot convert it, which is the most common way marketing budget gets wasted in this category.
1. Reduce time-to-first-result to a single step: Measure it literally: from landing on the repository to seeing the tool do something, count the steps and the elapsed minutes. Target one command or one hosted demo. For an inference tool, that means a runnable snippet with a real output shown, not a signup form.
2. Make one narrow, checkable claim: Pick the single measurement that best represents your advantage, publish the method alongside it, and publish where it does not hold. A claim with stated limits is more persuasive to this audience than a stronger claim without them, because limits are evidence that the measurement was real.
3. Publish the evaluation, not just the result: For AI and data tooling, the evaluation harness is a marketing asset. Releasing the dataset, the prompts, and the scoring script lets sceptical readers reproduce your number, and reproduction by a third party is the single strongest credibility event available in this category.
4. Treat the repository as the landing page: For technical audiences the README frequently receives more qualified attention than the marketing site. It should state what the tool does in one sentence, show a result within the first screen, and give a runnable command immediately.
5. Write documentation that answers evaluation questions, not just usage questions. Cost at scale, latency characteristics, failure behaviour, data handling, and how to remove the tool. Evaluation questions are the ones that block adoption, and they are almost never in the docs.
6. Show up where the problem is discussed, in the same words: Not with announcements. With answers, from named individuals who work on the tool, in threads where someone has the problem your tool solves.
7. Instrument activation, then work backwards: Define one activation event that means the user got value, such as first successful inference call or first completed pipeline run. Every channel is then judged on activations, not signups.
Steps one and two carry more weight than the remaining five combined. A tool that produces a verifiable result in one command with one honest claim attached can survive a bad launch. A tool without those cannot be rescued by distribution.
Which channels work, and which are noise?
Channel effectiveness in this category is unusually sensitive to whether the channel permits verification.
| Channel | What it is good for | Realistic expectation | Main failure mode |
| Repository and README | Primary evaluation surface, continuous | Compounds over months | Treated as an afterthought while the marketing site gets attention |
| Documentation and search | Capturing problem-aware demand | 2 to 3 quarters to compound | Written for existing users, not evaluators |
| Show HN and launch venues | One-day attention spike, occasional outsized result | 1.24% of AI launches clear 100 points | Treated as a strategy rather than an event |
| Technical community threads | Highest-intent audience available | Slow, requires named humans | Delegated to a marketing account and immediately discounted |
| Conference talks and workshops | Deep credibility with a small audience | Long lead time, durable | Measured on attendance rather than downstream adoption |
| Written benchmarks and evaluations | Third-party reproduction, citations | Highest credibility per unit of effort | Published without method, so unfalsifiable |
| Paid search and social | Reaching budget-holders, not practitioners | Works for enterprise motion only | Used to drive developers to a form |
The pattern across the table is that channels which allow the audience to check your work outperform channels that ask the audience to accept it. That is a durable property of this market rather than a trend.
How do you measure developer marketing?
Impressions and MQLs mislead badly here, because the person who adopts is frequently not the person who buys and the evaluation may run for months without a form fill.
| Metric | What it answers | Where to get it |
| Time to first successful call | Whether onboarding works at all | Product telemetry, signup timestamp to first successful response |
| Activation rate by source | Which channels bring qualified people | Activation event segmented by referrer |
| Repository clones and unique visitors | Genuine technical interest, ahead of signups | Repository traffic insights |
| Documentation depth per session | Evaluation versus bounce | Analytics on pages per docs session |
| Third-party reproduction | Whether your published claims survived scrutiny | Manual search for your benchmark name, quarterly |
| Unprompted mentions in technical threads | Whether practitioners recommend you without being asked | Periodic manual review, counted per quarter |
| Objection frequency in sales calls | Whether content is pre-answering evaluation blockers | Count of a named objection per quarter in call notes |
Pick one activation event and hold it constant for at least two quarters. Changing the definition mid-programme is the most common reason developer marketing produces no readable signal, and it happens more often than teams admit. For a fuller treatment of how these pieces fit together across a funnel, this breakdown of what developer marketing involves end to end is a reasonable starting point.
Where to start
You now have a measured picture of what launch outcomes actually look like in this category, four mechanisms that explain why working tools go unadopted, a seven-step sequence ordered so that early steps protect later spend, a channel table calibrated to verification, and a metric set that does not depend on form fills.
The first step takes an hour. Open your own repository on a machine with nothing installed, start a timer, and record how long it takes to see the tool produce a real result. If that number is above five minutes or the path includes an account, that is your constraint, and no amount of distribution will route around it.
Frequently Asked Questions
Is developer marketing just content marketing for a technical audience?
No. Content is one input. The distinguishing feature of developer marketing is that the product itself carries most of the persuasive load during a self-service evaluation, so the work includes onboarding, documentation, repository presentation, and the accuracy of published claims. A team that only produces articles is doing technical content marketing, which is a subset.
Should an AI startup launch on Show HN at all?
Yes, because the cost is close to zero and the tail outcome is large. Treat it as a lottery ticket with favourable pricing rather than a strategy. In our sample of 14,658 AI-related launches, 1.24% cleared 100 points and 62.5% received no comments at all, so plan the following six months on the assumption that nothing happens on launch day.
How do you market a developer tool without a community?
Start with documentation and search rather than community, because community requires an existing user base to seed it. Publish material that answers the exact evaluation questions blocking adoption, such as cost at scale and failure behaviour, and make the repository able to convert a cold visitor without any social proof.
What is a realistic timeline before developer marketing shows results?
Two to three quarters for pipeline signal, because technical evaluation cycles are long and often silent. Faster leading indicators exist: time to first successful call and documentation depth per session both respond within a single quarter and predict the later numbers reasonably well.
Do benchmarks help or hurt AI tool adoption?
They help when the method, baseline, hardware, and failure cases are published, and they hurt when only the headline number is. Given that Stack Overflow’s 2025 survey found 46% of developers actively distrust AI output accuracy against 33% who trust it, an unfalsifiable benchmark reads as a marketing claim and lowers credibility.
Who is the actual buyer for a developer tool?
Frequently two people. A practitioner adopts the tool and becomes the internal advocate, and a manager or platform owner approves the spend. Marketing to only one of them stalls: practitioner-only motion produces adoption without revenue, and buyer-only motion produces contracts that never get used and churn at renewal.