launch-and-growth

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:

1. A one-liner they understand in 5 seconds.
2. A visual proof it works — GIF, screenshot, or output block.
3. An install command that works on the first try.
4. A 5-minute path to a result they care about.
5. Evidence it is maintained — recent commits, a recent release, answered issues.
6. 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.