How to Post a Great Show HN on Hacker News

A great Show HN is a working thing people can try immediately, presented with a plain title, an honest first comment and an author who sticks around to answer questions. Hacker News readers are technical, skeptical and generous with feedback — if you respect their time, a Show HN can bring your first wave of serious users and some of the sharpest critique your product will ever get.

What is Show HN?

Show HN is the section of Hacker News for sharing things you've made. Posts appear on the main "new" feed and on a dedicated Show page, and the best ones reach the front page. The audience skews toward developers, founders and technical product people.

The core rule has been stable for years: a Show HN must be something people can try. That means a usable product, an open-source repo, a demo, a game or a tool — not a blog post, a waitlist or a "we raised a round" announcement.

Is my product a good fit for Show HN?

Some products fit naturally; others will struggle no matter how well you post.

Strong fit	Weak fit
Developer tools, CLIs, libraries, APIs	Pure marketing sites with no product
Open-source projects with a clear README	Products behind a mandatory signup or sales call
Technically interesting side projects	Generic wrappers with nothing novel underneath
Products with a free tier or live demo	Waitlists and "coming soon" pages

If your product is mostly a consumer app with little technical angle, Show HN can still work — but expect fewer engaged readers than on a general launch platform. For a broader comparison of where to post, see launch platforms vs directories vs leaderboards.

How do I write a Show HN title?

The title does most of the work. HN readers scan quickly and dislike hype.

• Start with "Show HN:" followed by the product name.
• Say what it does in plain words: "Show HN: Inkpad – a Markdown editor that syncs via Git".
• Avoid superlatives like "best", "revolutionary" or "the ultimate".
• Avoid clickbait and emoji. Specific beats clever.
• Mention what's unusual if there is something: "written in Rust", "runs entirely in the browser", "open source".

A good test: could a reader decide whether to click based on the title alone? If yes, it's working.

What should the first comment say?

Post a comment on your own submission right after it goes live. This is where you give context the title can't. A strong first comment covers:

1. Who you are and why you built it — the problem you personally hit.
2. What it does, in two or three sentences.
3. How it works — the stack, architecture or approach. HN loves real technical detail.
4. What's not done yet — honest limitations build trust.
5. What feedback you want — be specific: pricing, onboarding, performance, API design.

Keep it conversational and free of marketing language. Write it like you're explaining the project to a smart colleague.

How do I prepare the product before posting?

Your post can send a sudden spike of traffic from very demanding users. Prepare for it:

1. Remove friction. Offer a demo, a guest mode or a generous free tier. If signup is required, keep it to one step.
2. Load test lightly. Make sure the app won't fall over if hundreds of people arrive at once. Cache static pages and check database connection limits.
3. Polish the README or docs if it's open source. Many readers will judge the project by the repo alone.
4. Make the landing page explain itself in one screen: what it is, who it's for, how to try it.
5. Add basic analytics so you can see what happened afterwards — see our guide on measuring launch ROI.
6. Clear your calendar for several hours after posting.

When is the best time to post?

There's no guaranteed best time. Many makers aim for weekday mornings in US time zones, when a large share of readers are online, but quieter times can also work because there's less competition on the new page.

What matters more than the exact hour is that you are available for the next few hours to reply to comments. A thread where the author answers thoughtfully tends to hold attention far better than one where the author disappears.

How should I handle feedback and criticism?

Hacker News comments can be blunt. The best Show HN authors treat every comment — including harsh ones — as free user research.

• Thank people for trying it, even when they're critical.
• Answer the actual question. If someone asks why you didn't use an existing tool, explain the trade-off honestly.
• Don't argue about tone. Respond to the substance.
• Fix small things live if you can, and say so in the thread. Readers notice.
• Take notes. Recurring complaints are your roadmap.

Never ask friends to upvote or post supportive comments. Coordinated voting is against the site's norms and can get your post penalised. Sharing the link with people who will genuinely engage is fine; asking for votes is not.

What happens after the Show HN?

Whether your post hits the front page or quietly fades, the work isn't over:

• Follow up with commenters who signed up or asked for features.
• Write down what you learned — it makes great material for a later blog post or changelog.
• Keep launching elsewhere. A Show HN is one channel. Combine it with a Product Hunt launch and steady listings in relevant directories to keep discovery going after the spike ends.

If the first attempt didn't land, don't repost the same thing the next day. Ship meaningful improvements, then consider sharing again with a genuinely updated story.

A quick Show HN checklist

1. The product works and can be tried in under a minute.
2. Title starts with "Show HN:" and plainly says what it does.
3. First comment is drafted: why, what, how, limitations, feedback wanted.
4. Landing page or README explains the project on one screen.
5. Analytics and error monitoring are in place.
6. You have a few free hours to respond in the thread.
7. No vote requests to friends, colleagues or communities.

Show HN rewards substance over polish. Build something real, explain it honestly and listen closely — that's the whole playbook.