# Launch And Growth

> 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.

- Skill: `the-open-agent/launch-and-growth` (Agent Skill)
- Install (CLI): `npx skillmds@latest add the-open-agent/launch-and-growth`
- Raw SKILL.md: https://api.skillmd.com/api/skills/the-open-agent/launch-and-growth/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: the-open-agent (https://skillmd.com/u/the-open-agent)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/the-open-agent/launch-and-growth

---


# 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: <name> – <what it does>". 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.