| name | launch-and-growth |
| description | Get an open-source project in front of the people who need it, and keep them. Use when preparing to announce a project, writing a Hacker News or Reddit or Product Hunt post, planning a launch, writing a blog post about a release, improving GitHub discoverability (topics, About, social preview), or when the user asks how to grow adoption or get more stars. Covers launch readiness, channel selection and etiquette, what actually converts visitors into users, sustaining attention after launch, and honest expectations about star counts. |
Launch and Growth
Distribution is a real problem and ignoring it is not humility. But launches amplify;
they do not create. A launch sends a burst of traffic to whatever you have built — if
the README is confusing or the install is broken, you have spent your one shot at
those people's attention converting them into non-users.
Launch readiness
Do not announce until every one of these is true. Post-launch fixes reach nobody.
[ ] README passes the 30-second test (readme-that-converts)
[ ] Install command verified in a clean container, today
[ ] Quickstart produces a working result in under 5 minutes
[ ] A hero: screenshot, GIF, or a code sample under 10 lines
[ ] LICENSE present and declared in the manifest
[ ] A tagged release exists — not just a main branch
[ ] CI green, badge visible
[ ] Issue templates enabled
[ ] GitHub About: one-liner, link, topics
[ ] Social preview image set (Settings → Social preview)
[ ] You have 4+ uninterrupted hours to answer comments
[ ] Someone other than you has run the quickstart successfully
That last item catches more problems than the rest combined. Watch them do it without
helping — every question they ask out loud is a README fix.
Also, honestly: is it ready for strangers? Launching something half-finished burns
the audience you will want later. There is no penalty for launching two months late
and a real one for launching two months early.
GitHub discoverability
Free, permanent, and consistently neglected:
- Topics — up to 20; use them. This is how GitHub's own search and "explore" surface
you. Include the language, the domain, and the category (
rust, cli,
static-analysis, developer-tools).
- About — the one-liner and the docs URL. It is what shows in search results.
- Social preview image — controls what appears when your link is shared anywhere.
Without it you get a generic gray card, which measurably reduces clicks. Project
name + one-liner on a solid background is enough.
- Pinned repos on your profile and org.
- Releases — GitHub surfaces them, and package registries link back.
- A
<name>-awesome-list submission in your ecosystem's awesome list — small,
durable traffic.
Channels
| Channel | Audience | Etiquette |
|---|
| Hacker News (Show HN) | Broad technical | Title = "Show HN: – ". No hype words. First comment: why you built it, what it does not do. |
| Reddit | Language/domain subs | Read the rules; many ban self-promotion. Participate first. |
| Lobste.rs | Deeply technical | Invite-only, low tolerance for marketing. Tag accurately. |
| Product Hunt | Non-developer + founders | Better for products than libraries. Needs assets and a launch day. |
| Discord/Slack communities | Practitioners | #showcase channels. Ask first in large servers. |
| Your ecosystem's newsletter | High-intent | Rust Weekly, Python Weekly, JS Weekly, Node Weekly — free to submit, and the traffic converts unusually well. |
| Conference talk / meetup | Small, deep | Slowest, highest-trust. Best for adoption at companies. |
| A technical blog post | Search traffic, durable | Frequently outperforms every launch channel over 12 months. |
Do not blast all of them on one day. Pick the two where your users actually are. A
library for Rust developers gets more from Rust Weekly and /r/rust than from Product
Hunt, regardless of the numbers.
Show HN specifics
The most common source of a project's first thousand users, and the least forgiving.
- Title:
Show HN: Widget – a build tool that skips bundling in dev. No "blazing
fast", no exclamation marks, no emoji.
- Post the link to the repo, not to a landing page.
- First comment, immediately: what problem you hit, why existing tools didn't
solve it, what this does not do, and what state it's in. The self-deprecating
honest version outperforms the polished version, consistently.
- Answer every comment for the first several hours. Author responsiveness is
visible and it is what keeps a thread alive.
- Take criticism without defending. "Fair — that's a real limitation, it's in the
README under Limitations" earns more trust than a rebuttal. Arguing in a HN thread
is the most efficient way to convert interest into hostility.
- Do not ask for upvotes anywhere. It is detectable and it gets projects banned.
- Tuesday–Thursday, ~9am ET is the conventional window. It matters less than the
content.
- If it flops, that is normal. Most Show HN posts do. Repost in a few months with
a real update — this is explicitly allowed and works.
What actually converts
Traffic is not adoption. Between "clicked the link" and "uses it weekly" sit:
- A one-liner they understand in 5 seconds.
- A visual proof it works — GIF, screenshot, or output block.
- An install command that works on the first try.
- A 5-minute path to a result they care about.
- Evidence it is maintained — recent commits, a recent release, answered issues.
- Evidence others use it — download counts, a users list, testimonials. Weak at
launch and compounding afterward.
If your conversion is bad, the fix is almost always 1–4, not more launches.
After the launch
The spike lasts 48 hours. Everything durable comes after.
- Answer everything for a week. Issues opened during a launch are your highest-value
bug reports — those are motivated users telling you exactly where the friction is.
- Ship the top three complaints within two weeks, then say so publicly. "You asked,
here it is" is the most effective second post you will make.
- Write the technical deep-dive — how it works, what was hard, what you'd do
differently. This is the piece that gets linked for years and brings search traffic
long after the launch is forgotten.
- Show up where your users are. Answer Stack Overflow questions in your area. Fix
the integration in a downstream project yourself and open the PR. Adoption spreads
through people who already need this, not through announcements.
- Release regularly. A project with a release last month reads as alive; one with
the last release 14 months ago reads as dead, regardless of how finished it is.
Honest expectations
Nobody can promise a star count, and anyone who does is selling something. What is
actually true:
- Most useful projects never get 1,000 stars. Stars correlate with the size of the
addressable audience at least as much as with quality. A superb Erlang profiler will
lose to a mediocre JavaScript utility, permanently.
- Stars measure attention, not use. Plenty of 20k-star repos are dead; plenty of
400-star libraries are in production everywhere. Downloads, dependents, and issue
quality tell you more.
- Growth is compounding, not linear. Long flat stretches are the normal shape.
- Nothing beats solving a real problem. All of this skill is amplification, and
amplifying zero yields zero.
The healthy version of the goal: build something people depend on, make it easy to
find, and be present. If a project reaches ten thousand stars, it will be because of
that, and the practices in this repo are the ones that keep such a project from
collapsing under its own success.
Anti-patterns
- Launching a broken install command. You get one shot at those visitors.
- Astroturfing — sockpuppet upvotes, fake testimonials, coordinated comments. It
is detected, and the reputational damage is permanent.
- Buying stars. Visible in the follower graph of the accounts, and it destroys the
credibility of every other number you publish.
- Announcing the same project weekly. Communities ban this.
- Arguing with critics in public threads.
- Comparison marketing that trashes another project. The people you are trying to
impress mostly know and like that project.
- Launching, then vanishing for three months.
- Optimizing for stars. It leads to feature bloat, hype, and abandonment. Optimize
for the second visit.
- Treating a failed launch as a verdict on the project. It is a verdict on the
post, the timing, and the title.
