How to Launch on Show HN: A Practical Guide for Developer Tools

Show HN is one of the few places where a solo developer with a working tool can get serious technical feedback from strangers in a single afternoon. It is also easy to get wrong. Most failed Show HN posts don't fail because the product is bad. They fail because the post breaks a rule, hides the thing behind a signup, or reads like an ad.

This guide covers how to launch on Show HN the way the community expects: what qualifies, how to write the post, how to run the thread, and what to do after. It follows the current Show HN rules and Hacker News guidelines; check both before you post, since they change.

What Show HN is for

Show HN is a section of Hacker News for sharing something you made. The rules page defines it narrowly: something people can run on a computer or hold in their hands. For hardware, a video or detailed write-up is acceptable. For a book, a sample chapter works.

What qualifies

Per the Show HN rules, your post should be:

• Something you made. You worked on it personally and can answer questions in the thread.
• Non-trivial. The rules explicitly ask you not to post quickly generated one-offs.
• Easy to try. Ideally no signup and no email gate.
• Ready for users. Early is fine. Not usable yet is not. If it isn't ready, wait.

A major overhaul of an existing project may qualify. A routine version bump generally does not.

What does not qualify

The rules list these as off-limits for Show HN:

• Blog posts, sign-up pages, newsletters, lists and other reading material (submit these as regular stories instead)
• Landing pages and fundraisers
• Feature releases and upgrades

If your "launch" is a waitlist, it is not a Show HN. Build the thing people can try, then come back.

The rules that trip up developer tools

A few rules matter more than the rest for API, SDK and devtool launches.

Don't ask for votes or comments. The Show HN page says asking friends to upvote or comment is not ok, and the general guidelines say not to solicit upvotes, comments or submissions at all. That includes "we're on HN, go upvote" in your Slack, Discord or newsletter. Tell people you posted if you want, but don't ask them to vote.

Don't post AI-generated text. The current HN guidelines ask users not to post generated or AI-edited text. Write the title and your first comment yourself. Use an agent to check your demo works, not to write your voice.

Don't delete and repost. The guidelines say deletion is for posts that shouldn't have been submitted, not for a second try at better timing.

Self-promotion in moderation. The guidelines say HN shouldn't be used primarily to promote your own work. Posting your own project occasionally is fine. Posting every minor release is not.

Before you post: make it trivially easy to try

The single biggest lever is time to first success. A reader clicks through, and you have one screen to get them to something working.

Do this:

• Put a live demo, a playground or a one-command install above the fold.
• If an API key is required, offer a test key or sandbox that works without a sales call.
• Make the README answer three questions in order: what it does, how to run it, what it looks like when it works.
• Remove the email gate. If you need accounts for the full product, let people try a meaningful slice without one.

A good bar: a developer on a fresh machine reaches a working result in under five minutes. Test this with someone who has never seen the project.

Writing the post

The title

The title must start with Show HN:. After that, say plainly what it is. The general guidelines ask for no all caps, no exclamation points and no editorializing. Treat that as the style for your own title too.

Default pattern: Show HN: [Name], [what it does] [for whom or how]. Concrete nouns beat adjectives every time.

The link

Point the submission at the thing people can try: the repo, the demo, or the docs page with the quickstart. Not a marketing landing page.

The first comment

Post a comment right after submitting. The Show HN page encourages explaining how and why you built it. This is where you earn the thread. Keep it short and specific:

1. One or two sentences on the problem and why you built it.
2. How it works, with one interesting technical detail.
3. What's rough or missing, stated honestly.
4. The kind of feedback you want.

Hi HN, I built this because I kept hand-writing mocks for third-party APIs
and they drifted from reality within a week.

It runs as a local proxy, records real responses, and writes them to plain
JSON fixtures you can commit. Replays are deterministic, including timestamps.

Rough edges: no gRPC yet, and the Windows install is untested.

I'd especially like feedback on the fixture format and whether the proxy
approach is a dealbreaker for your setup.

No pricing pitch, no "sign up for early access," no list of investors.

Running the thread

Block out the day. The value of Show HN is the conversation, and the rules expect you to be there for it.

• Answer every substantive question. Fast, specific and technical.
• Say "you're right" when they're right. Concede bugs and gaps plainly. File the issue and link it.
• Don't argue with tone. Answer the technical point under a harsh comment and move on. The Show HN page asks commenters to be respectful; you hold yourself to the same standard.
• Keep your team from piling in. Coworkers posting praise reads badly and edges into vote solicitation.

Every Show HN appears on the shownew page. Per the rules, after it gets a small number of points it moves to the show page. You cannot control that, so don't try. Focus on the people already in the thread.

After the launch

Whatever happens on the front page, the thread is research data.

• Copy every question into a doc. Repeated questions are gaps in your README or docs.
• Fix the top three onboarding complaints within a week.
• Don't repost the same thing soon. Wait until there's a genuinely new, substantial version.

Show HN launch checklist

• Read the current Show HN rules and HN guidelines pages
• Product is something you built, non-trivial, and usable today
• No signup or email gate to try the core experience
• Fresh-machine test: working result in under five minutes
• README covers what it does, how to run it, what success looks like
• Title starts with Show HN:, plain and specific, no hype
• Link points to the repo, demo or quickstart, not a landing page
• First comment drafted by you: why, how, what's rough, what feedback you want
• No vote or comment requests anywhere, including team chat and newsletters
• Demo and infrastructure ready for a spike; error tracking open
• Calendar cleared to answer questions for the day
• Feedback log ready; follow-up fixes scheduled for the week after

Do this next

Show HN is one channel on one day. The work that makes it land, a clear one-line description, a quickstart that actually works and a plan for the week after, is the same work that makes every other channel land.

If you want the full plan, The Developer Launch Kit gives you the positioning canvas, launch-day run of show and six-week runway as fill-in templates, with a worked example and agent skills to draft them from your repo. Get it here: https://shiptodevs.com/#pricing

Sources

• Hacker News, "Show HN" rules: https://news.ycombinator.com/showhn.html
• Hacker News Guidelines: https://news.ycombinator.com/newsguidelines.html
• Y Combinator blog, "Make Things and Show Them": https://www.ycombinator.com/blog/make-things-and-show-them