You do not get flamed on Hacker News for having a rough product. You get flamed for marketing speak, for begging for upvotes, and for going quiet when someone asks a hard question. So launch a thing people can actually try, write a plain title, drop a first comment that reads like a person explaining their work, and then sit in the thread all day answering everything, including the criticism. That is most of it. HN rewards a real artifact and an honest founder, and it has a very good nose for anything that smells like a campaign.
This post is about the one channel. For how a Show HN fits into a full launch, read the devtools launch playbook.
What actually belongs on Show HN
Show HN is for something the reader can look at or run themselves. A repo, a live demo, a playground, a CLI they can install in one command. If your link goes to a signup wall or a “book a demo” page, you are in the wrong place, and the thread will tell you so within minutes.
The bar is not polish. Half-finished side projects hit the front page all the time. The bar is that the thing exists and does what you say. HN readers are mostly engineers evaluating whether your tool solves a problem they have. They forgive missing features and rough edges. They do not forgive a landing page dressed up as a product.
A few things that do not belong: a funding announcement, a “we’re excited to share” blog post, a waitlist, a pure marketing site. Those can be regular submissions if the content is genuinely interesting, but they are not Show HN, and mislabeling them reads as trying to game the tag.
How do you write the title
Say what it is in the fewest plain words possible. “Show HN: ” followed by a description of the tool and what it does. No adjectives, no hype, no “revolutionary.” The community strips that out of your title in their heads anyway, and it costs you credibility before anyone clicks.
Compare these two:
| Weak title | Better title |
|---|---|
| Show HN: The fastest way to ship AI agents | Show HN: A CLI for running local LLM agents against your codebase |
| Show HN: We reinvented observability | Show HN: Trace every DB query in a request without adding code |
| Show HN: The future of API testing | Show HN: Open-source Postman alternative that runs in your terminal |
The pattern on the right is boring on purpose. It names the category, the shape of the thing, and the concrete outcome. An engineer skimming the front page can decide in two seconds whether it is relevant to them, which is exactly what you want. If your title needs an adjective to sound interesting, the problem is usually the positioning, not the title. That is a different fix, and it is in positioning a technical product.
The first comment is where you win or lose
Post a comment on your own thread within the first couple of minutes, before anyone else shows up. This is the single highest-leverage thing you do, and a lot of founders skip it. The first comment is where you get to be a person instead of a headline.
Write it like you are telling a friend what you built and why. What itch did you scratch. What it does and does not do yet. What is genuinely hard about the problem. What you are unsure about and want feedback on. If it is a side project, say so. If there is a commercial version coming, say that too, plainly. HN respects a founder who names the business model instead of hiding it.
Keep it short and specific. Skip the origin story about your co-founder’s dorm room. Do include the stuff engineers actually want: how it works under the hood, what you built it on, the tradeoff you made and why, and the limitation you already know about. Naming your own weak spot first takes the wind out of the person who was about to name it for you, and it makes everything else you say more believable.
Being present in the thread
Clear your calendar for launch day. The founder answering questions in real time, thoughtfully, for hours, is the thing that turns a decent thread into a good one. Threads die when the poster drops the link and disappears, and they get suspicious when the only replies are three fresh accounts saying “great product.”
Answer everything, in order, including the boring questions and the ones you have answered already. When someone asks how it compares to an existing tool, answer straight, name the competitor, and say where you are genuinely worse. When someone finds a bug, thank them and, if you can, fix it and reply that it is fixed. That kind of visible responsiveness does more for you than any feature you could have shipped that morning.
Talk like yourself, not like a support macro. No “thanks for the feedback, we’ll take that on board.” Engineers can smell corporate voice from across the internet, and it reads as a company trying to manage them. Some of this is the same muscle as writing content engineers respect, which I get into in developer content engineers respect.
Handling criticism without making it worse
Assume you will get criticized. Some of it will be fair, some will be a person who skimmed your title and formed a strong opinion, and some will be needlessly harsh. Your job is the same for all three: stay calm, engage the substance, and never get defensive in public.
When the criticism is fair, agree with it. “You’re right, that’s a real limitation, here’s how we’re thinking about it” is a genuinely good look and often gets upvoted above the original complaint. When it is a misunderstanding, clarify gently and assume good faith, because the person you are really talking to is the hundred lurkers reading the exchange, not the one commenter. When it is just rude, answer the technical part and ignore the tone. Do not match it.
The one move that reliably makes things worse is arguing to win. You will not out-argue a hostile HN thread, and trying makes the whole front page watch you lose your composure. A founder who takes a hard question well is more convincing than the product itself. A founder who gets prickly torpedoes an otherwise fine launch.
Timing and the mechanics
Post on a weekday morning US Eastern time, roughly 7 to 10am, when the US is waking up and Europe is still around. That gives your submission the most hours of daylight to gather early traction, and early traction is most of what decides whether the ranking algorithm carries you up. Avoid Friday afternoons and weekends, when traffic is thinner. There is no perfect slot, so do not agonize; just do not post at 9pm on a Saturday.
Some mechanics worth knowing. Do not ask anyone to upvote you, not in the thread, not on Twitter, not in your team Slack. HN actively detects voting rings and will bury a post where the votes look coordinated, and telling people to go upvote is the fastest way to trigger that. You can tell people you launched and let them find it. That is the line, and it matters. Post from an account with some history rather than one created that morning, since brand-new accounts posting a polished launch look exactly like what they often are.
If your post does not take off, that is normal and not a referendum on your product. The front page is noisy and partly luck. You are allowed to try again another day with a better title or a more finished demo. Just do not repost the identical thing hours later the same day.
What not to do, in one place
- No marketing copy in the title or first comment. Plain language only.
- No asking for upvotes, anywhere, ever.
- No astroturfing. Sockpuppet accounts and coordinated “wow, love this” comments are obvious and fatal.
- No link to a signup wall or demo-booking page as your main submission.
- No disappearing after you post. If you cannot be there for the day, launch another day.
- No arguing to win, and no deleting critical comments you can reply to instead.
What a realistic outcome looks like
A good Show HN sends a spike of high-intent, technical traffic, a burst of GitHub stars or trial signups, a handful of genuinely useful bug reports and feature ideas, and sometimes a lasting bump in how your category perceives you. It rarely produces a pipeline of closed deals by itself, and that is fine. It works best as the top of a funnel you have actually built out underneath, so the engineers who show up curious have docs, a demo, and a clear next step waiting.
That matters because so much of the evaluation happens before anyone talks to you. The 2025 State of Marketing to Engineers report found 60 percent of the buying process happens online before an engineer engages with sales. A Show HN is one of the sharpest ways to reach people inside that 60 percent, on a day when they are paying attention. Waste it on marketing speak and you have burned a rare shot. Use it well and you get the most honest product feedback you will ever collect, in public, for free.
If you want a launch sequenced so Hacker News is one strong beat inside a bigger plan rather than the whole bet, that is the work I do. See the case studies or get in touch.
