Key Stats
| Metric | Data |
|---|---|
| Upvotes needed for front page | ~30–50 in first hour |
| Typical front page Show HN total | 200–600 points |
| Best posting time | 9–10 AM ET weekdays |
| HN traffic to GitHub (front page) | 500–2,000 stars |
| AFFiNE HN front page appearances | Multiple (incl. month 12 spike) |
| Comment engagement on strong Show HN | 50–200 comments |
| Grace period (downvote-protected) | First few hours |
TL;DR
- Show HN is the right format — it gets a dedicated queue, downvote grace period, and HN community actively browses it
- Post 9–10 AM ET weekdays; your first 30 minutes determine front page trajectory
- Title format: "Show HN: [What it is] – [one differentiator]" — no hype, no exclamation marks
- First comment = your pitch. Write it before you submit. Technical depth, honest limitations, specific ask
- Respond to every comment in the first 2 hours — engagement velocity matters to the algorithm
- A front page Show HN drives 500–2,000 GitHub stars for OSS tools; traffic drops fast but the HN point signal persists
Why Hacker News Is Different
Most launch platforms optimize for volume. Hacker News optimizes for signal.
The community is ~10 million monthly readers, but the active voting core is a much smaller group of engineers, founders, and researchers who are genuinely hard to impress. They will immediately identify vague claims, marketing language, and anything that doesn't hold up technically. They will also — when something is genuinely interesting — drive it to the front page and generate the kind of discussion that gets your project noticed by journalists, investors, and developers who won't be found anywhere else.
For AFFiNE, Hacker News was part of the coordinated Day 1 launch with Reddit. The initial Show HN coincided with the Reddit push that drove 6,000 GitHub stars in week one. A later HN front page appearance at month 12 produced another significant spike — at that point we already had strong product-market fit, and the HN community could see it in the depth of user comments.
The dynamic is simple: HN doesn't reward polish. It rewards technical honesty and genuine novelty.
The Show HN Format: What It Gets You
When you start a post with "Show HN:", three things happen:
- It appears on news.ycombinator.com/shownew — a dedicated queue that HN regulars browse specifically for new projects to try
- It receives a downvote grace period — new Show HN posts can't be downvoted immediately, giving them time to accumulate genuine interest before criticism
- The self-promotion rule doesn't apply — HN normally discourages posting about your own work; Show HN is the sanctioned exception
There's also an implicit social contract: Show HN posts are expected to be genuinely showing something — a working product, an interesting open source repo, a tool you built. Not a blog post about why you might build something, not a landing page with no product behind it.
If you're launching an open source project or a developer tool with real functionality, Show HN is exactly the right format.
Timing: When to Post
HN's front page algorithm is sensitive to early velocity. You need your core supporters to upvote within the first 30–60 minutes, which means you need them awake and at their computers.
The optimal window:
- Monday–Thursday, 9–10 AM ET — Peak HN activity. US East Coast engineers are starting work; West Coast is at their desks; European audience is mid-afternoon.
- Sunday, 10 AM ET — Second-best option. HN Sunday traffic is slightly lower but the audience is more exploratory. Competition is lower.
- Avoid: Friday afternoon, Saturday. Traffic drops and HN's weekend patterns favor long-read content over discovery.
One nuance: Monday has slightly more competition (experienced teams often launch early in the week). If you're concerned about a strong competitor launching the same day, Tuesday or Wednesday reduces collision risk.
Practical setup: Have your post drafted, preview it, then schedule your supporters to be ready before you submit. The first 30 minutes after posting are not the time to be sending messages asking people to look at it.
Writing the Title
HN titles are unusually formulaic — and that's a feature, not a bug. The community has optimized the format over years of collective experience.
The Show HN title format:
Show HN: [What it is] – [one specific differentiator]
Examples that work:
Show HN: AFFiNE – an open-source Notion alternative with local-first storageShow HN: A Rust-based database that runs entirely in your browserShow HN: I rebuilt my photo management app after iCloud raised prices 3x
What doesn't work:
-
Show HN: The future of note-taking is here!— Hype language gets downvoted reflexively -
Show HN: We launched our startup— No technical signal -
Show HN: Better than Notion— Comparative claims without basis irritate HN readers -
Show HN: ProjectName— No information; nobody will click
The differentiator in your title should be the technically interesting part — the architecture choice, the open source angle, the local-first approach, the specific problem you solved. HN readers are scanning for novelty. Give them a reason to open the tab.
Title length: Keep it under 80 characters. Titles that wrap in HN's layout look amateurish.
The First Comment: Your Most Important Asset
On Hacker News, the submitter's first comment is read before the product in most cases. It's visible directly below the title before anyone clicks your link. This is your pitch.
Write it before you submit. Do not improvise it after posting.
Structure that consistently works:
- What you built, in one sentence — not the marketing version, the technical version
- Why you built it — a specific, personal problem you faced, not "there was a gap in the market"
- The interesting technical choice — what's architecturally different, why you made that tradeoff
- One honest limitation — this is critical. HN rewards intellectual honesty. Admitting what doesn't work yet signals you're a serious engineer, not a marketer
- Specific ask — what kind of feedback are you looking for?
Example structure (AFFiNE-style):
We've been building AFFiNE for two years — it started as frustration with Notion's sync latency and Obsidian's collaboration limitations. Most of the note-taking tools we tried forced a choice: real-time collaboration OR local-first storage. We wanted both.
The interesting technical piece: we built a conflict-free replicated data type (CRDT) layer underneath the editor so documents can live locally and sync when online, without a centralized server holding your data hostage.
Current limitation: the mobile app is rough. Desktop and web are solid; iOS/Android still has performance issues we're working through.
If you try it, I'm especially curious whether the canvas/block combination makes sense to you or whether it feels like too much — that's the feedback we haven't been able to resolve internally.
Notice: no "check out our amazing tool," no exclamation marks, no feature list. One real problem, one honest limitation, one specific question.
Building Your Support Network Before Launch
The first 30 minutes after posting are what determines your front page trajectory. You need a small group (10–30 people) who are:
- Active HN users with karma — votes from accounts with no history are worth less and are more likely to trigger HN's fraud detection
- Genuinely interested in your project — they'll write comments that help, not hollow "+1 great project" posts that get flagged
- Available at the time you post — timezone coordination matters
Where to find them:
- Your existing Discord/Slack community — ask who uses Hacker News
- Twitter/X connections who are engineers or founders
- Personal network of developers you've met at conferences or in communities
What to ask for:
"I'm launching on Hacker News tomorrow at 9 AM ET. Link: [URL]. If it looks interesting to you, any feedback in the comments would mean a lot — I'm trying to figure out [specific question]."
Never say "please upvote." It reads as manipulation and HN regulars will sometimes downvote your post specifically if they see coordinated upvote requests. Ask for engagement (comments, feedback) not votes. Genuine engagement produces votes as a byproduct.
Managing the Comments Section
Once your post is live and gaining traction, the comments section is where HN launches succeed or fail.
Respond within 15 minutes to every substantive comment in the first 2 hours. HN's algorithm weights comment velocity as a signal of engagement quality. A post with 30 comments and active back-and-forth will continue to surface; a post with 30 comments and no replies from the submitter stalls.
How to respond:
- Technical objections: engage seriously. "Good point — we went with X because Y, but you're right that Z is a tradeoff." Don't be defensive.
- Feature requests: "That's on the roadmap / that's not something we've planned — here's why."
- "Why not just use [competitor]?" — The most common HN comment. Have a prepared answer that's honest. Not marketing.
- Genuine compliments: A short thank-you + one piece of additional context keeps the thread active.
What not to do:
- Don't argue with critics. If someone is wrong, calmly state the accurate information and move on.
- Don't ask people to upvote in the comments.
- Don't self-promote repeatedly in your own thread. One maker comment + responses only.
A well-managed comment section can sustain a front page post for 18–24 hours. A post where the founder disappears after submitting typically fades in 4–6 hours.
The Technical Depth Requirement
Hacker News has an implicit minimum standard for "technically interesting." Consumer apps, landing pages, and non-technical products routinely underperform — not because HN is elitist, but because the audience is self-selecting toward technical depth.
For developer tools and open source projects, this works strongly in your favor. Things that reliably resonate:
Architecture choices: "We replaced [standard approach] with [novel approach] because of [specific constraint]." HN loves reading about tradeoffs.
Open source code: Link directly to GitHub. A repo the community can inspect is substantially more trusted than a closed-source product. "You can read the implementation here" is a strong signal.
Real numbers: Benchmarks, query speeds, memory usage, scale metrics. Not "10× faster" but "10× faster at 10M rows on an M2 MacBook, benchmark code in /tests."
Honest failure stories: "We tried X and it didn't work because Y. So we built Z." HN appreciates intellectual honesty about the path you took.
If your product doesn't have technical depth yet — if it's mostly UI/UX innovation on top of standard infrastructure — wait. HN Show HN is not the right channel until you have something technically interesting to say.
What Happens After Front Page
Traffic from HN front page is fast and focused. Unlike Reddit (broad awareness) or Product Hunt (wide developer audience), HN traffic tends to be:
- High-intent: they clicked through specifically because of the technical angle
- Comment-heavy: expect more GitHub issues, Discord questions, and direct emails per visitor than from other platforms
- Conversion-variable: OSS tools see strong star conversion (500–2,000 stars for a front page appearance); SaaS products see lower trial conversion but higher-quality leads
The traffic pattern: 60% of your HN-referred traffic arrives in the first 6 hours, 80% within 24 hours. By day three, HN traffic is negligible.
What to prepare before your post goes live:
- GitHub README updated and star CTA visible
- Email capture on your landing page
- Discord/Slack invite link in your maker comment
- Response drafts for the most predictable comments ("why not X?" "how does this compare to Y?")
After the spike — the persistent value:
The HN submission URL (news.ycombinator.com/item?id=XXXXX) becomes a permanent link that continues to drive occasional traffic for months. Developers who search for your product category sometimes land on old HN threads. A well-commented thread with substantive discussion is evergreen content.
More importantly: journalists and investors regularly monitor HN for interesting projects. A front page appearance with 200+ points is visible in their HN monitoring. The AFFiNE launch threads contributed to several inbound media mentions that wouldn't have found us otherwise.
Show HN vs. Other HN Formats
Show HN — for working products, tools, open source projects. Use this.
Ask HN — for genuine questions where you want community input. Sometimes appropriate pre-launch ("Ask HN: Best architecture for [problem]?"). Don't pitch your product in an Ask HN.
Regular submission — for blog posts, technical articles, research. If you write a "how we built X" post about your project, you can submit the article as a regular link. This is a second-bite approach: write a deep technical post about your project 2–4 weeks after your Show HN, then submit the article. Different format, different audience, second exposure.
One useful pattern: Show HN on launch → technical blog post 2–3 weeks later → submit blog post. The first submission establishes you in the HN community; the blog post submission reaches people who missed the original Show HN.
Checklist: Day Before, Launch Day, Follow-Up
Day before:
- [ ] Write your first comment (the pitch) and save it
- [ ] Prepare answers to the 5 most predictable technical objections
- [ ] Alert 10–20 genuine supporters to be available at posting time
- [ ] Ensure GitHub README has a clear star CTA and demo link
- [ ] Set up email capture on landing page
Launch day (post at 9–10 AM ET):
- [ ] Submit with correct title format: "Show HN: [What] – [differentiator]"
- [ ] Immediately post your first comment
- [ ] Notify supporters with the live link
- [ ] Respond to every substantive comment within 15 minutes for the first 2 hours
- [ ] Monitor HN ranking — if you're not front page within 1 hour, consider whether to resubmit another day
Follow-up (days 2–7):
- [ ] Write a "we just launched Show HN" post in relevant Reddit communities (link to HN thread, not product page)
- [ ] Thank people who commented with direct replies or DMs if they left contact info
- [ ] Begin drafting your technical blog post for submission in 2–4 weeks
- [ ] Check GitHub issues — HN users file detailed bug reports and feature requests
Common Mistakes That Kill Show HN Posts
Marketing language in the title. "Revolutionary," "game-changing," "10× better" — these phrases trigger HN's collective allergic response. Describe, don't hype.
Not being available for the first 2 hours. Post at a time when you can monitor and respond. Posting at midnight in your timezone because "that's 9 AM ET" and then sleeping means your launch window passes without engagement.
Submitting before the product is ready. HN users will try your product immediately. If the onboarding is broken, if the demo doesn't work, if it's clearly not ready — the comments will reflect that, and those comments are permanent.
Posting to your own account with no karma. A fresh account submitting a Show HN looks like marketing. If possible, have someone with HN karma and genuine community standing submit on your behalf, or build up some HN karma by commenting substantively on other posts before your launch.
Ignoring the thread. The single most common mistake. You post, it gains traction, and then you're unavailable for 4 hours. The engagement dies, the ranking drops, the opportunity closes. Block your calendar for the morning of your launch.
📚 Related Reading
More tools → Growth Tools Directory
Top comments (0)