A Hacker News launch is easy to remember badly.
The founder remembers whether the post reached the front page. The repo remembers something more useful: who starred it, forked it, opened issues, tried the install path, and came back after the first burst.
For an open-source AI tool, the GitHub repo is not a backend artifact. It is part of the launch page.
Measure the first week, not only the first hour
HN star-window ledger before launch retrospective is the first operating habit. Track 24 hours, 48 hours, and 7 days.
The diffusion study found average star gains of 121 in 24 hours, 189 in 48 hours, and 289 in a week after HN exposure. The point is not that every repo should hit those numbers. The point is that the shape of the curve tells you whether the launch created a quick glance or a trust trail.
Pick a posting window you can support
HN posting-hour test before front-page hope sounds tactical, but it is really about readiness.
If timing can change the number of stars by hundreds, the launch window should not be random. Pick a time when the relevant readers are likely awake and when the team can answer comments, fix small docs problems, and watch the repo while the thread is live.
Make the repo useful before strangers arrive
HN repo ready before community attention is the most practical move in the batch. A separate study found HN exposure was followed by significant increases in forks, stars, and contributors across AI GitHub projects.
That means the README, install path, demo, examples, issue labels, and license are not polish. They are conversion surfaces for technical trust.
The Show HN label is not the product
HN Show label after substance, not before keeps the founder honest. The diffusion paper found no statistical advantage from the Show HN tag after controls.
The label can frame a good artifact. It cannot make an unfinished artifact feel ready. HN is unusually good at noticing that difference.
Turn the launch into data you can reuse
HN public API launch tracker before vanity summary is a small antidote to folklore. The research pipeline used public APIs and finished in under five minutes.
A founder version can be much simpler. Save the post timestamp, score, comment count, GitHub stars, forks, contributors, issues, and docs clicks. Then write down what changed at 24 hours, 48 hours, and 7 days.
Do not poison the trust graph
GitHub authentic star quality before star buying is the guardrail. Star count matters only because developers believe it says something about real attention.
The fake-stars research is a warning: suspected fake-star activity surged in 2024, and the short-term lift can become a long-term liability. For a technical product, that is a terrible trade. Real stars, issues, forks, contributor notes, and external writeups age better.
If I were preparing a technical launch this week, I would make the repo useful before the post, pick a window the team can support, measure the first week, and protect the trust graph like it belongs to the product. Because for developer tools, it does.
If you want help turning technical launches, repo proof, and source-backed pages into a cleaner growth system, Ian Goh works with founders through Ian Goh advisory.