Show HN Checklist: How to Post Without Getting Buried

The official Show HN rules are about 350 words long and they tell you what is allowed, not what a good post looks like. That gap is where most launches die. A Show HN that works has four things: a project people can actually run today, a title that begins with "Show HN" and states plainly what the thing does, a first comment written by hand that gives the backstory and names the limitations, and you sitting in the thread for the next several hours answering everyone. The post is the invitation. The comments are the launch.

What follows is a line by line reading of the rules Hacker News publishes, with the title and first comment patterns that satisfy each one. I have quoted the guidelines rather than paraphrased them, because a lot of the launch advice in circulation describes rules that have since changed.

What qualifies as a Show HN and what gets removed?

The Show HN guidelines draw one hard line: "Show HN is for something you've made that other people can play with." On topic is "things people can run on their computers or hold in their hands." For hardware you can post a video or a detailed article. For a book, a sample chapter.

Off topic, in the guidelines' own words: "blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out, so can't be Show HNs." Those still belong on Hacker News as regular submissions. They just cannot carry the Show HN tag. The page is also explicit that you should not post landing pages or fundraisers, and that if your work is not ready for users to try, you should wait and come back when it is.

Three more qualifying rules that catch people out:

• Non-trivial only. "Don't post quickly-generated one-offs; anybody can do that now." That sentence is recent and it means what it says. A weekend wrapper around somebody else's API is a hard sell in 2026.
• Version bumps are not launches. New features and upgrades in the shape of "Foo 1.3.1 is out" are generally not substantive enough. A major overhaul probably is.
• It has to be yours and you have to be there. The project must be something you worked on personally and are around to discuss.

There is also a friction rule that is really a distribution rule: "Please make it easy for users to try your thing out, ideally without barriers such as signups or emails. You'll get more feedback that way." A login wall between the reader and the thing is the single most common self-inflicted wound in a Show HN. If your app genuinely needs an account, put a hosted demo, a sandbox, or a real video behind the link instead.

Why do marketing-shaped titles get flagged?

Nothing on Hacker News detects marketing tone automatically. People do. Flagging is a user action, and a title that reads like an ad invites it before anyone has clicked through.

The submission rules in the main site guidelines are specific about titles. Do not do things to make titles stand out, "like using uppercase or exclamation points, or saying how great an article is." If the title includes the name of the site, take it out, because the site name is displayed after the link anyway. If it contains a gratuitous number or a number plus an adjective, crop it. And in the moderator tips on presenting your work, which the Show HN page links to directly: "Drop any language that sounds like marketing or sales. On HN, that is an instant turnoff. Use factual, direct language."

Here is the teardown. The project below is an invented example, not a real launch. Call it Specdiff, a command line tool that compares two OpenAPI documents and reports what changed.

The title as most founders first write it:

Introducing Specdiff by SpecdiffHQ: The #1 API Breaking Change Detector Modern Teams Trust! 🚀

The title after editing:

Show HN: Specdiff finds breaking changes between two OpenAPI specs

Edit	Rule it satisfies
Added the "Show HN" prefix	"To post, submit a story whose title begins with Show HN"
Cut "Introducing" and "by SpecdiffHQ"	"If the title includes the name of the site, please take it out"
Cut "The #1"	"If the title contains a gratuitous number or number + adjective, we'd appreciate it if you'd crop it"
Cut "Modern Teams Trust" and the exclamation point and the emoji	"Please don't do things to make titles stand out, like using uppercase or exclamation points, or saying how great an article is"
Replaced the category label with what it does to what input	"Include a clear statement of what your project is or does"

The rewritten title is duller and that is the point. A reader scanning the new page decides in about a second whether they have a use for an OpenAPI diff tool. The first title makes that decision harder, not easier. The same discipline applies to your app store subtitle and your directory listing, which is why writing an app tagline is worth doing before launch week rather than during it.

One more from the tips page that people miss entirely: "Don't have your username be that of your company or project. It creates a feeling of using HN for promotion and of not really participating as a person." If your account is named after the product, change it before you post.

What belongs in the first comment?

The moderator tips ask for text "giving the backstory of how you came to work on this, and explaining what's different about it," because that "tends to seed discussion in a good direction." The text should appear at the top of the submission, and if for some reason it does not, add it as a first comment. Either way is fine. Post it immediately, not twenty minutes later.

There is a rule here that predates almost every launch guide you will find and now sits in the site guidelines in plain sight: "Don't post generated text or AI-edited text. HN is for conversation between humans." The tips page adds a note dated 2026-03-28 saying to write your text by hand and not use a language model for any of it, including to edit or polish, because the community is unusually sensitive to it right now. Read that as a warning about your launch, not a moral position. Use models for the work if you like. Write the thread yourself.

The first comment as most founders first write it:

Hey HN! 👋 We're super excited to finally launch Specdiff, the API change detection platform trusted by modern engineering teams. Start your free trial today and let us know what you think. Would really appreciate your support and upvotes!

The first comment after editing:

I maintain three public APIs at work and kept shipping breaking changes by accident. Code review caught naming mistakes and missed the ones that mattered: a required field added to a request body, an enum value removed, a 200 that quietly became a 202.

Specdiff parses two OpenAPI 3 documents and prints what changed, classified as breaking, non-breaking, or unknown. Single binary, no account, no server. There is a paste box on the site if you want to try it without installing anything.

The hard part was not the diff, it was deciding what counts as breaking. Adding an optional response field is safe for most clients and breaks strict-validation ones, so those land in the unknown bucket with an explanation instead of the tool silently picking a side. The rules live in one file if you want to argue with them.

What it does not do yet: OpenAPI 2, JSON Schema outside the spec, and it has no opinion about your versioning. I would mostly like to know whether the unknown category is useful in practice or just annoying.

Edit	Rule it satisfies
Opened with the specific problem at a real job instead of a greeting	"Include text giving the backstory of how you came to work on this"
Second paragraph says exactly what it takes in and prints out	"Include a clear statement of what your project is or does"
Cut "excited", "trusted by modern engineering teams", "free trial"	"Drop any language that sounds like marketing or sales"
Named the no-install paste box	"Please make it easy for users to try your thing out, ideally without barriers such as signups or emails"
Third paragraph is the design decision, not the feature list	"Personal stories and technical details are great"
Fourth paragraph lists what is missing and asks one real question	Seeds the discussion, and the thread is the point
Deleted the request for upvotes	"Please don't ask friends to upvote or comment. That's not ok on HN"

That last one is not a soft convention. The FAQ says asking people to upvote or comment can get submissions, accounts, and sites penalized or banned, and adds the practical warning that readers detect it and call it spam. The same applies to friends dropping supportive comments in your thread. Genuine feedback from someone who actually uses the thing is fine. Cheerleading is not.

How should you handle a harsh top comment?

Assume the top comment will be critical. Hacker News rewards a good critical comment, and someone who spent ten minutes finding the flaw in your architecture has given you more than a hundred upvotes would.

The comment guidelines that apply to you as the author are the ones about responding to "the strongest plausible interpretation of what someone says," not being curmudgeonly, and keeping comments substantive as the topic gets more divisive. In practice, four responses cover almost everything:

• They found a real flaw. Say so, say whether you knew, say what you will do. "You're right, and I did not have a good answer for that when I built it" is the highest-value sentence in any launch thread.
• They compared you to an existing tool. Answer the comparison honestly, including where the other tool is better. Never claim a difference you cannot demonstrate.
• They misread what it does. That is a documentation bug. Fix the sentence on your site during the thread and say you did.
• They are just being dismissive. The guidelines discourage shallow dismissals, and other readers usually handle those. You do not have to.

Do not argue about scope, do not explain that they are not the target user, and do not reply to the same person three times. The audience for your reply is the silent majority reading the thread, not the commenter.

What do you do if the post sinks in twenty minutes?

First, understand what you are watching. Every Show HN lands on the shownew page, and only once it clears a small points threshold does it appear on the show page in the top bar. The FAQ describes ranking as points divided by a power of the time since submission, with user flags, anti-abuse software, software that demotes overheated discussions, account or site weighting, and moderator action all affecting it. Nothing published tells you a best hour to post, and anyone selling you one is guessing. A quiet twenty minutes usually means nobody found it, not that you were punished.

What not to do is documented plainly. Do not delete and repost. Deletion is for things that should not have been submitted at all. Do not message friends. The FAQ says reposts are acceptable only when a story has not had significant attention in the last year or so, and the tips page suggests reposting once or twice a year at most, always with a comment linking the previous thread and explaining what changed. It also suggests putting your email address in your profile, partly so moderators can send you a repost invite, which they do sometimes.

Then get on with the rest of your launch, because a sunk Show HN costs you an afternoon and nothing else. Work the other places worth posting your app, including the Product Hunt alternatives that suit smaller launches, and keep doing the slow direct work that gets your first hundred people to try it. A front page day is a spike. Distribution is what survives the week.

Frequently asked questions

Can I post a landing page as a Show HN?

No. The guidelines list sign-up pages and other reading material as off topic for Show HN specifically because they cannot be tried out, and the page tells you not to post landing pages or fundraisers. The moderator tips are blunter: the project has to actually exist and there has to be a way for people to try it. If you only have a waitlist page, it can still be a regular HN submission if it is genuinely interesting, but it is not a Show HN.

Does time of day matter on Hacker News?

Hacker News does not publish a best time to post, and its documented ranking is points divided by a power of the time since submission, plus flags, anti-abuse measures, weighting and moderator action. What that structure implies is simple enough: a post needs early votes to survive the decay, and it starts on a low-traffic page where relatively few people see it. Post when you can be present in the thread for the following several hours, which matters far more than the clock.

Can I post the same project twice?

Yes, sparingly. The FAQ allows a small number of reposts when a story has not had significant attention in the last year or so, and buries the rest as duplicates. The moderator tips say you can post a new release as a Show HN only if the new version is significantly different rather than an incremental upgrade, and that this should probably happen once or twice a year at most. When you do, link the previous thread and say what changed. Deleting and reposting the same story is explicitly not allowed.

Should I reply to every comment?

Reply to every comment that contains a question or a real objection, including the rude ones. Skip the pure noise. Threads close to new comments after two weeks, so there is no rush after day one, but the first several hours are when your replies shape how the thread reads to everyone arriving later.

---

A Show HN gives you one afternoon of attention and then the thread scrolls away. A listing keeps working: it stays indexed, it keeps getting browsed by people who like trying new things, and it costs you ten minutes once. When your launch day is done, submit your app to TryMy free. It is human-reviewed, the listing links straight to your site, and free apps, free trials and freemium apps all qualify.