Hacker News can send the right kind of early attention to a technical product. It can also expose a weak launch in minutes.
The difference is not a clever posting time or a network of friends waiting to upvote. It is whether you have something the community can actually try, a clear explanation of why it exists, and the patience to discuss the work honestly.
This checklist is based on the current Hacker News guidelines and Show HN rules, not recycled launch folklore.
First decide: Show HN or a regular submission?
Use Show HN when all four statements are true:
- You personally worked on the product.
- People can use or test it now.
- The work is substantial enough to discuss.
- You will be available to answer questions.
Show HN is not for a waitlist, newsletter, blog post, fundraiser, or signup-only landing page. If the main thing people can do is read, use a regular submission. If the product is not ready to be tried, keep building.
That distinction matters because Hacker News is not a generic launch directory. The community expects to inspect the thing, question the trade-offs, and learn something from the builder.
Make the product easy to try
Every extra gate reduces the quality of feedback.
Before posting, test the experience in a private browser window and on a phone. A visitor should understand what the product does and reach its core value without needing a demo call or a long onboarding flow.
For a SaaS MVP, aim for one of these:
- a usable demo without an account;
- a sample workspace with realistic data;
- a short signup that immediately opens the product;
- a public repository with direct setup instructions;
- a video only when the product cannot reasonably be tried online.
Also test the boring failure points: email delivery, OAuth callbacks, mobile layout, empty states, password reset, rate limits, and your error page. The MVP launch checklist covers the operational checks that are easy to miss when you are focused on the announcement.
Write a plain title
A Show HN title should begin with Show HN: and say what the thing is.
Good titles usually follow one of these patterns:
Show HN: A local-first tool for comparing CSV filesShow HN: I built a visual debugger for webhook payloadsShow HN: An open-source scheduler for small clinics
The title should not claim that the product is revolutionary, guaranteed, effortless, or the first of its kind. Hacker News asks submitters not to use titles as promotional copy. Plain language earns more trust and gives readers a reason to inspect the work themselves.
Prepare the first comment before launch
The product page explains what exists. Your first comment should explain the decisions behind it.
Cover five things:
- The trigger: What specific problem made you build this?
- The user: Who has the problem often enough to care?
- The approach: What does the product do differently?
- The trade-offs: What did you deliberately leave out?
- The question: What kind of feedback would be most useful?
Technical readers will often ask about architecture, data ownership, privacy, pricing logic, model choice, open-source alternatives, and why the product needs to exist. Prepare direct answers. “We used X because it let us test Y quickly, but it creates Z limitation” is stronger than pretending every choice is permanent.
Do not manufacture engagement
Do not ask friends, customers, a community, or an audience to upvote or comment. Do not coordinate a burst of votes. Do not delete and repost because the first attempt was quiet.
The official guidance is unambiguous: people should vote because they independently find the submission interesting. Manufactured activity does not just risk moderation; it poisons the feedback because you can no longer tell whether the response is real.
Your goal is not to “win Hacker News.” Your goal is to learn whether technically curious strangers understand the product, can use it, and find the underlying problem interesting.
Stay for the conversation
Post only when you can remain available for the next few hours.
Answer the strongest version of each question. If someone identifies a real limitation, acknowledge it. If a comparison is fair, explain why you still chose your approach. If a comment is merely dismissive, you do not need to turn it into a debate.
Do not paste generated replies. Hacker News currently prohibits generated or AI-edited comment text because the site is meant for conversation between humans. Write as the builder. Specific, imperfect answers are better than polished corporate language.
Capture feedback in three buckets:
- Blockers: the product fails, is confusing, or cannot be tried;
- Positioning: readers misunderstand the user or problem;
- Product ideas: useful, but not automatically roadmap commitments.
Use the five-metric MVP analytics framework to connect the traffic spike to behavior inside the product. Page views alone will not tell you whether the launch produced learning.
A 24-hour Show HN checklist
Product
- Core workflow works in a fresh browser session
- Mobile layout does not block the main action
- Demo or sample data is available where possible
- Error tracking and uptime alerts are active
- Analytics capture activation, not only visits
Submission
- The project qualifies for Show HN
- Title begins with
Show HN:and describes the product plainly - First comment explains problem, approach, trade-offs, and feedback request
- No launch group has been asked to vote or comment
- You can stay available to respond
After posting
- Fix blockers before debating feature requests
- Record repeated questions as positioning evidence
- Separate criticism from actual user behavior
- Publish a short follow-up for your own notes
- Decide the next experiment only after the traffic spike settles
The correct success metric
A front-page appearance is pleasant but not a product milestone.
A useful Hacker News launch gives you clearer language, sharper objections, a list of product failures, and a few users who experience the problem strongly enough to keep using the product after the thread disappears.
That is the standard: not applause, but evidence.