Launching on Hacker News without breaking the rules

Hacker News publishes its rules, they are short, and most failed launches break one of them in the first thirty seconds. Not by being too commercial — by posting something that was never eligible, or by asking for the one thing you are not allowed to ask for. Here is what the rules say, and how to launch inside them.

What a Show HN is, and what it is not

The Show HN page defines it in one line: "Show HN is for something you've made that other people can play with."

That word — play — is the whole eligibility test. The page then names what does not qualify, and the list is the reason most marketing launches are dead on arrival:

Off topic: blog posts, sign-up pages, newsletters, lists, and other reading material. Those can't be tried out, so can't be Show HNs.

And, more bluntly, the rule that catches a product launch aimed at a waiting list:

If your work isn't ready for users to try out, please don't do a Show HN. Once it's ready, come back and do it then. Don't post landing pages or fundraisers.

The other conditions are easy to meet if you are the team that built the thing, and impossible to fake if you are not:

• "The project must be something you've worked on personally and which you're around to discuss." Clear your calendar for the day.
• "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 demo behind a form is a landing page with extra steps.
• "A Show HN needn't be complicated or look slick. The community is comfortable with work that's at an early stage." Rougher than you think is fine; unusable is not.
• Version bumps do not count: "New features and upgrades ('Foo 1.3.1 is out') generally aren't substantive enough to be Show HNs. A major overhaul is probably ok."

There is also a line added for the current era, and it is worth reading if your plan was to ship something quickly for the attention: "The project should be non-trivial. Don't post quickly-generated one-offs; anybody can do that now."

The guideline every marketing team breaks

It is in both documents, and it is unambiguous. From the guidelines:

Don't solicit upvotes, comments, or submissions. Users should vote and comment when they run across something they personally find interesting—not for promotion.

The Show HN page says it again in its own words: "Please don't ask friends to upvote or comment. That's not ok on HN."

This is not a norm you can quietly ignore. Voting rings are the thing HN's moderation is best at detecting, and the penalty arrives silently: the post stops rising, and nobody tells you why. A Slack message to twenty colleagues with a link in it is the most expensive message in a launch.

Three more from the guidelines that decide how a submission reads:

• Titles. "Please don't do things to make titles stand out, like using uppercase or exclamation points, or saying how great an article is." Also, take the site name out of the title — HN prints the domain itself.
• The original source. "Please submit the original source. If a post reports on something found on another site, submit the latter." Your press coverage is not the submission; your thing is.
• Promotion as a share of your activity. "It's ok to post your own stuff part of the time, but the primary use of the site should be for curiosity." An account that has only ever submitted its own company is legible as exactly that.

And one that applies to how the thread is handled, not the post: "Don't post generated text or AI-edited text. HN is for conversation between humans." If your launch-day plan involves an assistant drafting replies, it is a plan to break a written rule in public, under your own product's name.

The thread is the launch

The submission is the smaller half. What decides a Show HN is the first hour of replies, and the person answering has to be the person who built the thing.

• Answer the harshest comment first, and answer it straight. An evasive reply to a technical objection is read by everybody who arrives later.
• "We chose X because Y, and it breaks at Z" earns more than any claim you could make about the product. Naming a limitation is how you are believed about everything else.
• Do not argue about whether a criticism is fair. Fix what is fixable, acknowledge what is not, and stay in the thread.
• Do not accuse anyone of astroturfing or brigading, however the thread goes. The guidelines specifically ask you not to: "Please don't post insinuations about astroturfing, shilling, brigading... If you're worried about abuse, email hn@ycombinator.com and we'll look at the data."

When it sinks

Most launches do. A Show HN that got four points and no comments is not a verdict on the product; it is a verdict on the hour, the title, and the fifty other things posted alongside it.

There is a documented route back, and almost nobody uses it. HN runs a Second-Chance Pool: moderators and reviewers pick over old submissions that deserved attention and re-lob them onto the front page at random. It is public, and it takes requests. In dang's own explanation of how it works:

If you see a submission that didn't get attention and which you think is particularly good for HN, please tell us at hn@ycombinator.com! We love getting those requests and usually add them to the pool. It's fine if it's your own article, but we like it better when it's just something you ran across and recognized as good.

So: one polite email, no pitch. What is not an option is deleting the post and trying again — "Please don't delete and repost. Deletion is for things that shouldn't have been submitted in the first place."

What we do

We do not submit on a client's behalf and we do not vote on a client's submission, because both are exactly what the guidelines describe. What we do is the preparation: reading the thing the way a hostile commenter will, cutting the title back to what it is, making sure the demo runs without a signup, and being on hand while the team answers the thread.

If the honest read is that a product has nothing anybody can try yet, we say so and pass, and the work becomes something else — a positioning problem, usually, rather than a launch one.