How to launch a developer tool on Hacker News

Hacker News sends more qualified traffic to a new developer tool in an afternoon than most teams get in a quarter. It is also the channel where the most launches go quiet with four upvotes and no comments. The difference is rarely luck alone. It is usually whether you had something people could try, and whether you were honest about what it does.

What Show HN actually is

Show HN is a submission category for things you made that other people can try right now. It has its own feed, separate from the main front page, and everything posted there also competes on the main page by the same rules as any other story.

The requirement that trips people up is "can try". A waitlist page is not a Show HN. Neither is a blog post about your architecture, a fundraising announcement, or a signup form behind an invite code. If the only thing a reader can do is submit their email address, the post belongs somewhere else and the comments will say so.

Read the Show HN rules on HN itself before you post. They are short, they are enforced, and the rest of this guide assumes you have followed them.

The title format

The convention is plain and unadorned:

Show HN: Toolname – what it does in a few words

That is the whole format. What works inside it:

• Name the job, not the category. "Show HN: Branchdb – Postgres branches for every pull request" tells a reader exactly what they are about to get. "Show HN: Branchdb – rethinking the database workflow" tells them nothing.
• Use words your user already uses. If your audience says "preview environment", do not invent "ephemeral stack instance".
• Say the constraint out loud if it is interesting. "in 40 lines of Go", "with no dependencies", "under 5 MB" earn clicks honestly, because they are checkable.

What reliably hurts:

• Adjectives about your own product. "Blazing fast", "beautiful", "revolutionary" read as a signal that the substance is thin.
• "We are excited to announce". HN titles are not press releases.
• Emoji, all caps, exclamation marks, and question-mark bait.
• Editorializing. The site guidelines ask you not to add your own spin to titles, and that norm applies to your own product too.

Do not put your pitch in the URL field's text box either. Link to the thing itself: the demo, the repo, or the docs page where the install command lives. Save the story for your first comment.

What actually gets traction

Posts that do well on Show HN tend to share a few properties. None of them are about marketing.

A reader can get to the interesting part without an account. A hosted demo with sample data, a playground, a single npx or curl command, a binary they can run. Every gate between the link and the interesting part costs you a fraction of your readers, and signup is the most expensive gate there is.

The problem is specific and recognisable. HN readers are professionals who have hit real problems. "I got tired of X and built Y" works when X is something they have also been tired of.

There is something to talk about technically. A hard constraint you worked around, a benchmark with the method published, a design tradeoff you can defend. Comment volume is what keeps a post visible, and comments come from substance.

The scope is honest. "This handles the 80% case and here is what it cannot do" is a stronger opening than a claim you will spend the next four hours walking back.

What gets ignored or actively punished: thin wrappers with a pricing page and no demo, "AI-powered" as the entire value proposition, tools that only make sense inside your own company, and anything that looks like it was posted by a marketing team rather than the person who wrote the code.

Timing, and how much it matters

HN ranking is a function of upvotes against the age of the post, with penalties applied for various things. That has two practical consequences.

The first is that the front page is a race won in the first hour or two. If nothing happens in that window, a post usually stays buried. So post when you can sit with it. Being present for the first two hours matters more than any particular clock time.

The second is the tradeoff nobody can resolve for you: US weekday mornings carry the most traffic and the most competition, weekends carry less of both. Anyone who tells you a precise best hour is guessing. What you can control is that you are awake, at a keyboard, with notifications off and the deploy already done.

Two more practical points:

• Post once, from the right account. Do not delete and repost to try again, and do not have a colleague submit it so you can both comment as if you are strangers. Vote rings and sockpuppets are the thing HN's moderation is best at catching.
• Never ask for upvotes. Not in a group chat, not in your newsletter, not in a Slack community. It violates the guidelines, it is detectable, and a penalised post cannot be un-penalised by enthusiasm.

The first comment

Post one comment on your own submission, immediately, from the account that submitted it. This is where the context goes that does not belong in the title:

• Who you are and why you built this
• What it does today, in one paragraph
• What it does not do yet, honestly
• The stack, and one interesting decision inside it
• Licensing and pricing, if either exists
• What feedback would be most useful to you

Keep it short enough to read in twenty seconds. This comment does more work than anything else you write that day, because it is what people quote when they reply.

Handling the comments

The comments are the launch. Traffic follows them.

Answer every substantive question, and answer the critical ones first. The harshest comment in the thread is usually the most useful, and how you respond to it is what undecided readers judge you on. "You are right, that is a real limitation, here is why we shipped anyway" is a good answer. "Great point, we have that on the roadmap" is not, because everyone has read that sentence a hundred times.

A few things worth doing:

• If someone finds a bug, fix it that day if you can, then reply to them saying it is fixed. This is visible and it changes the tone of a thread.
• If someone misunderstands what the tool does, that is a documentation bug. Fix your README or landing page copy while the thread is live, then say you clarified it.
• If someone compares you to a competitor, answer factually, including where the competitor is better. Pretending otherwise fails in front of an audience that has used both.
• Disclose anything relevant: that you work for the company, that a benchmark ran on your own hardware, that the hosted version is the paid one.

Do not argue about whether the project should exist. Do not reply to every compliment. Do not go quiet halfway through, which is the most common failure: people stop answering after three hours and a thread that was going well stalls.

Survive the traffic

Assume the spike arrives in minutes and is concentrated on one page. Before posting:

• Put the demo behind a CDN, or make it fully static, or run it client-side
• Cache the landing page and make sure your video is small and lazy-loaded
• Know what happens when your database connection pool is exhausted, and make it a friendly error page rather than a stack trace
• Turn off anything that emails you per signup unless you want thousands of emails
• If there is a hosted free tier, set a rate limit you can defend, and say what it is

An outage during a Show HN is survivable and people are usually sympathetic, but a blank page in the first hour costs you the run.

What happens after

HN traffic decays fast. Within two or three days you are back to baseline, and the useful question is what you kept.

Things that persist: GitHub stars and the people who actually cloned the repo, subscribers to a list you own, bug reports from strangers, and the thread itself, which stays searchable and is often the first thing someone reads about you a year later. Things that do not persist: the number at the top of the post.

So convert while the traffic is there. One clear path from your landing page to something durable, whether that is a mailing list, a Discord, or a repo to watch. Update the listing for your tool so people arriving later see the current state rather than the pre-launch teaser, and make sure it shows up on the already launched list rather than as upcoming. Our pre-launch playbook covers the weeks that lead up to this day, and the open source launch checklist covers what needs to be in the repository before the traffic arrives.

If the post got no attention at all, that is normal and it is not fatal. HN's own FAQ describes a second-chance pool for posts that did not get a fair look, and tells you that you can email the moderators about it. You can also simply ship more, and post again in a few months with something more interesting. Repeat Show HN posts from the same project are fine when there is genuinely something new.

The honest takeaway

Hacker News is not a growth channel you can operate reliably. It is a single high-variance event where the controllable part is the quality and honesty of what you put in front of people, and the uncontrollable part is everything else. Treat it as one entry in a sequence rather than the launch itself: our guide to where to launch a developer tool covers how it fits alongside Product Hunt, Reddit, and your own list. Build something that works without a signup, say plainly what it does and does not do, then stay in the thread until the questions run out.