Who it's for
Growth marketing for devtools, executed.
Developers do not respond to marketing, they respond to being taught something and to people who were useful before they sold anything. That makes devtools distribution slow, technical, and hard to delegate. Zway runs it with human operators who participate in your communities properly, draft with your engineers, and never post generated text where the platform bans it.
Last reviewed 27 August 2026
The bottleneck
The problem with how devtools usually do this.
Developers detect marketing inside one sentence and their default response is to close the tab, which eliminates most of the channels other companies rely on. Three things still work and all three are slow: technical writing deep enough that the reader learns something, being genuinely useful in a community long before you mention the product, and documentation good enough to be the reason someone picks you. Devtools founders can produce all three and almost never have the hours, so the work that would pay best is the work they do least.
Developer marketing is mostly the absence of marketing
Your buyer has spent a decade being sold to badly and has developed an accurate filter. Superlatives, urgency, testimonials with job titles, anything written in the voice of a brand rather than a person: all of it gets discarded before the second paragraph.
What survives the filter is narrow. Something that teaches. Something that admits a limitation. Someone who answered a question in a thread six months ago and did not mention their product. Documentation that saved an afternoon.
That is a short list, and none of it is fast. It is also why devtools companies with no marketing team sometimes beat funded competitors: the work rewards depth and patience rather than budget.
Hacker News and Reddit cannot be run by software
This is the clearest case on the whole site, because the platforms have written it down.
| Platform | What automation can do | What it cannot |
|---|---|---|
| Hacker News | Read the public API, which is read-only | Submit, vote, reply, flag. The robots file disallows every one of those paths to agents, with a 30 second crawl delay |
| Hacker News | Help you prepare | Post generated or AI-edited text. The guidelines prohibit it outright |
| Post through approved API access | Operate commercially without a separate agreement, or post substantially similar content across subreddits | |
| Satisfy sitewide rules | Satisfy a moderator, who independently decides what is unwanted in their community |
So the drafting can be assisted and the judgement cannot. Our operators read the thread, understand the subreddit, write the reply themselves, and carry the consequences of getting it wrong. That is the part that is expensive and it is the part that works.
Docs are where the evaluation actually happens
A developer evaluating your product spends most of their time in the documentation, not on the homepage. Docs are also the surface most likely to be cited when someone asks an assistant how to do a specific thing with your tool, because they are structured, exact, and unhedged.
Most devtools docs have the same failure pattern: excellent reference, thin conceptual material, and a quickstart that works only on the maintainer's machine. We audit for the pages where people give up, then write the missing conceptual and troubleshooting pages. That work looks nothing like marketing and it moves more signups than most campaigns.
Volume is lower here, and that is correct
Developer distribution is not a high-frequency activity. A weekly technical piece, daily community reading with a small number of genuinely useful replies, and a submission only when there is something actually worth submitting. That is the whole shape of it.
Anyone proposing five posts a day across four platforms for a developer audience has not run this before. At that volume the writing thins out, the community reads it as promotion, and the accounts get removed long before the frequency pays for itself.
What stays with your team
We do the research, the interviews, the drafting, the posting, the community participation, and the log. Technical accuracy is checked by one of your engineers before anything ships, usually in under twenty minutes per piece. We will not publish a technical claim your team has not read, because a wrong benchmark in front of this audience is not a correction, it is a thread.
Channels that work here
- Hacker News, as a reader and commenter first, submitter rarely
- Reddit in the specific subreddits your users already live in
- Technical long-form that teaches something with no product in it
- Documentation treated as a distribution surface, not an obligation
- Founder posting in the developer register rather than the marketing one
The first thirty days
What a first month looks like for a devtools company.
| Week | Focus |
|---|---|
| Week 1 | Engineering interview. Find the three things your team knows that are not written down anywhere public. |
| Week 2 | Community mapping and account audit. Operators begin reading and replying where your users are, with no product mention. |
| Week 3 | First deep technical piece published. Docs audit delivered, covering the pages that lose people. |
| Week 4 | Founder posting begins. Community participation continues and the first genuinely useful answers go out. |
Questions at this stage
Can any of this be automated?
Will Hacker News penalise us for AI-written posts?
How do we post on Reddit without being removed?
Is the 1 in 10 rule real?
Are docs really a growth channel?
See the plan for your company.
Thirty minutes. You leave with a written thirty-day plan either way.
30 minutes. You leave with the plan either way.