Two launches a week apart, for audiences that want opposite things. Readiness gates, timing, first-comment structure, and the week calendar.
Read the guide, then turn it into a concrete plan for your brand.
Launching an open-source product is not one launch. It is two, staged a week or two apart, aimed at audiences that want opposite things: Hacker News wants the architecture and the honest caveats, Product Hunt wants the outcome and the screenshots. This is the operating playbook — gates, timing, copy structure, and what to measure.
Pick one end-to-end walkthrough that represents the product actually working — install, first meaningful action, visible result — and make passing it the precondition for scheduling anything. A launch that sends traffic to a broken quick start converts curiosity into a permanent negative impression, and you only get the attention once.
Once that gate is green:
Every row needs public evidence, not an assurance.
| Area | Required outcome |
|---|---|
| README | Explains the product, quick start, architecture, links, license, and contribution path. |
| Demo media | A GIF or screenshots showing the core loop end to end, not a static hero image. |
| Architecture overview | Public docs describe the boundaries between the open core and anything commercial. |
| Quick start | A clean-clone install has actually been run, by someone who is not you if possible. |
| Screenshots | Current UI, never mockups. Reviewers notice. |
| CONTRIBUTING | Branch policy, checks, and PR expectations are public. |
| Issue templates | Bug and feature reports guide contributors without exposing private process. |
| Analytics | Attribution is wired before traffic arrives, not during. |
Use one campaign name across every channel so the cohort is comparable:
utm_campaign=oss_launch| Channel | Source | Medium |
|---|---|---|
| Show HN submission | hacker_news | show_hn |
| Show HN first comment | hacker_news | comment |
| Product Hunt link | product_hunt | launch |
| Maker comment | product_hunt | comment |
| Launch article | devto | article |
| X thread | x | social |
| LinkedIn post | social |
Track stars from baseline to T+24h, T+72h, and T+7d; signups carrying launch UTMs; activation within the launch cohort; and self-hosting signals such as quick-start page views, image pulls, and issues opened by new visitors.
Link the public repository or public docs. Never a staging URL. Keep the title plain and descriptive — Hacker News titles that try to sell get flagged, and titles that just say what the thing is do fine.
Show HN: [Product] - [what it is in five words]Post it yourself, immediately, and structure it in four parts:
Have short, factual replies ready for: can I self-host it, do I need a cloud account, what is the licence, how do I contribute, and how does it compare to the obvious incumbent. Answer the comparison question honestly — including where you lose — because the thread will find out either way and being first is worth more than being flattering.
Run it one to two weeks after Show HN. The delay lets you fold in HN feedback, refresh screenshots, and avoid splitting the conversation across two audiences on the same day.
Write four tagline candidates and pick the one that would make sense to someone who has never heard of the category. Keep the short description to two sentences: what it is, and how you run it.
Different audience, different register from HN. Lead with the problem you personally had, describe the loop your product closes, and end by asking for feedback from the specific kind of user you want.
| Asset | Purpose |
|---|---|
| Hero image | Explain the category in one frame, using real UI. |
| Core workflow | Show the main loop with readable labels. |
| Fast win | Show the thing that takes ten seconds and feels good. |
| Planning surface | Show the product in use over time, with demo data. |
| Integrations | Show what it connects to, no private handles. |
| Self-hosting proof | Terminal or architecture, free of secrets. |
| Time | Action |
|---|---|
| T-48h | Freeze copy, screenshots, and links. |
| T-24h | Confirm the product page, maker access, gallery, and UTM links. |
| 12:01am PT | Launch. |
| First 2h | Reply to everything. Ship doc fixes live. Write down every objection. |
| First 24h | Publish the technical article and owned-channel posts. |
| T+24h | Record traffic, stars, signups, activation, self-hosting signals. |
| T+7d | Publish the retrospective and link the follow-up issues. |
| Day | Channel | Content |
|---|---|---|
| D-7 | Blog | Why the project is open source and self-hostable. |
| D-5 | X | Build-in-public thread with a quick-start GIF. |
| D-3 | Founder and use-case post. | |
| D-1 | GitHub | README, screenshots, and issue templates frozen. |
| D0 | Hacker News | Show HN submission and first comment. |
| D+1 | Technical blog | Architecture and setup walkthrough. |
| D+3 | X and LinkedIn | What the HN feedback changed. |
| D+8 to D+14 | Product Hunt | Launch page and maker comment. |
| D+15 | Blog | Public retrospective with results and next steps. |
Record stars, forks, signups, activated users, image pulls, and quick-start views before the first submission. Without a baseline every post-launch number is unreadable. Define activation concretely — a launch-cohort user who completes the product's first real action — and treat it as the only number that predicts anything about week four.
The playbook is deliberately boring. Launches fail on unglamorous things — a broken install command, an unanswered licence question, no attribution on the one day traffic actually arrives — far more often than on positioning.