How to launch a dev tool on Hacker News (Show HN)
A practical, honest playbook for launching a developer tool on Hacker News with a Show HN: the title formula, the body, timing, what not to do, and how to draft it from a GitHub release.
What this solves
A maker is about to launch a developer tool and wants a realistic, non-spammy playbook for doing a Show HN well rather than getting flagged or ignored.
How S2P helps
Run a Show HN that reads like a real builder sharing real work: a specific title, an honest top comment, the right timing, and a draft pulled from your release.
Key takeaways
- Hacker News rewards human, non-promotional posts; a press-release tone gets flagged or ignored.
- The title is plain and specific; the top comment carries the story and the honesty.
- Timing, a working link, and staying in the thread matter as much as the copy.
- Your GitHub release notes are the raw material; draft from them, then make it human.
Section 1
What a Show HN actually is
Show HN is not an ad slot. It is a convention for showing the community something you made and inviting them to poke at it.
Show HN is a specific category of Hacker News post for sharing something you built that people can try right now: a tool, a site, a library, a hardware project. The unwritten contract is that it is your work, it is reachable without a signup wall or a waitlist, and you are genuinely open to feedback. That last part is not decoration. The audience can tell within one comment whether you want a conversation or a conversion, and they respond accordingly.
The reason this matters for a dev tool is that the Hacker News crowd is disproportionately the exact person you are building for: engineers, founders, and people who evaluate tools for a living. They are also the most marketing-allergic audience on the internet. The same post that would do well on LinkedIn - confident, benefit-led, lightly hyped - will get downvoted or flagged here. Show HN is high-signal precisely because the bar for honesty is high.
So the mental model is not launch. It is share. You are walking into a room of skeptical peers and saying here is the thing I made, here is what it does, here is what it does not do yet, what do you think. Get that framing right and the mechanics below are easy. Get it wrong and no title formula will save you.
- Show HN is for things people can try now, not waitlists or teasers.
- The audience is your buyer and your harshest reviewer at once.
- Frame it as sharing work for feedback, not running a campaign.
- Honesty about limitations is a feature here, not a weakness.
Section 2
The title formula
The title is the single highest-leverage decision, and the winning move is to be boring and specific instead of clever and vague.
A good Show HN title states what the thing is in plain words. The format the community expects is literally Show HN: followed by a short, concrete description. No superlatives, no clickbait, no exclamation marks. Revolutionary, AI-powered, and game-changing are all signals to scroll past. The titles that work read like a person describing their project to a colleague: factual, specific, and a little understated.
Specificity does the persuading. Show HN: A tool to post GitHub releases to social media is clear and tells the reader exactly what they will get if they click. Show HN: The future of developer marketing is empty and will be punished. If your tool has a sharp, unusual angle, the title is where that angle earns the click - but the angle has to be a real, concrete capability, not an adjective. When in doubt, describe the job your tool does in the fewest plain words possible.
One honest caveat: you cannot edit the title after a window, and the title is most of your fate on the front page. Write three or four candidates, read them as a stranger would, and pick the one that a busy engineer would understand in under two seconds. The body is where nuance lives; the title only has one job, which is to make the right person click and the wrong person scroll on without flagging you.
- Use the plain Show HN: prefix and a concrete description.
- Cut every superlative; specificity beats hype here.
- Name the job your tool does, not the vision behind it.
- Write several candidates and pick the clearest, not the cleverest.
Section 3
The top comment: your real pitch
On Show HN, your first comment is the post. It is where you earn trust, set context, and give people a reason to actually try the thing.
Immediately after submitting, post a top comment from your own account. This is where the story goes. A structure that works: one or two sentences on what you built and the specific problem it solves, one or two on why you built it - the real itch, told honestly - and then a short, plain description of how it works and what is and is not done yet. End by inviting feedback on something concrete, because a specific ask gets specific answers.
Honesty is the whole strategy. Name a real limitation before anyone else does: this only supports a few channels so far, or the onboarding is rough, or I have not load-tested it past X. Counterintuitively, naming the weakness buys credibility and pre-empts the top critical comment, which often becomes the most upvoted reply and sets the tone of the thread. A post that pretends to be finished and flawless reads like marketing; a post that is upfront about the rough edges reads like a builder, and builders get the benefit of the doubt.
Keep the commercial stuff quiet and truthful. If there is a paid plan, it is fine to mention it plainly when asked, but the top comment should be about the work, not the pricing page. Link to something people can use without friction. If your tool needs an account, say so and explain why, and make the path as short as possible. The fastest way to lose the thread is to send a skeptical engineer to a signup wall before they have seen value.
- Post a top comment yourself the moment the submission goes live.
- Say what it is, why you built it, and what is not done yet.
- Name a real limitation before a commenter does - it builds trust.
- Link to something usable without a wall; keep pricing talk honest and minimal.
Section 4
Timing and what to do during the launch
A great post at the wrong time sinks. The launch is not the submission; it is the hours you spend in the thread after it.
Weekday mornings US time tend to give the most runway, because the post has the whole American workday plus the European afternoon to gather early upvotes that decide whether it climbs. Avoid late Friday and weekends, which are quieter and harder to break out of. None of this is a guarantee; the front page has a large element of luck, and a strong post can still stall. Treat timing as stacking the odds, not buying a result.
The non-negotiable part is presence. Block out the two to three hours after you submit and spend them in the thread. Reply to every substantive comment, thank people for harsh feedback, answer questions fast, and update your top comment if a recurring confusion emerges. Threads that have an engaged, gracious author climb; threads where the author drops the link and disappears die. Your responsiveness is itself a ranking and trust signal to everyone reading.
Stay calm with criticism, because there will be some, and the way you handle it is on display. A defensive reply to a critical comment does more damage than the criticism itself; a thoughtful reply where you concede the fair points and explain your thinking wins the room. Do not ask friends to upvote or comment - vote rings get detected and penalized, and it poisons the honest signal that makes Hacker News worth launching on in the first place.
- Aim for a weekday morning US time; skip Fridays and weekends.
- Treat timing as improving odds, not guaranteeing the front page.
- Stay in the thread for hours and answer every real comment.
- Never organize upvotes; vote manipulation gets detected and punished.
Section 5
What not to do
Most Show HN failures are self-inflicted. The fastest way to do well is to avoid the moves that get posts flagged or ignored.
Do not write like a press release. Marketing language, buzzwords, and breathless benefit copy are the clearest possible signal that you do not understand the room, and they get downvoted on sight. Do not gate your tool behind a waitlist, a mandatory demo call, or a hard paywall, because Show HN is for things people can actually try. Do not argue with critics or get defensive; do not vote-ring; and do not repost the same launch every week hoping for a better roll.
There is also a deeper anti-pattern worth naming, because it is relevant to anyone building release-marketing automation: do not treat Hacker News as just another channel in a cross-posting firehose. Auto-posting a generic launch blast to HN the way you might to LinkedIn or X is the surest way to get flagged. The community values deliberate, human, one-time submissions. The right move is to draft with help but submit by hand, as yourself, with a comment you actually wrote.
This is exactly why a good release-marketing tool should make Hacker News a deliberate, human step rather than an automated push. S2P can take your release and draft a Show HN-ready title and body so you are not staring at a blank box, but it does not auto-submit to Hacker News, and that restraint is the point. You stay the human in the loop because that is what the channel requires and what actually works.
- No press-release tone, buzzwords, or hype copy.
- No waitlists, forced demos, or hard paywalls in front of the link.
- No arguing with critics and no organizing upvotes.
- Do not auto-blast HN like a normal channel; submit by hand, as yourself.
Section 6
Drafting your Show HN from a GitHub release
You do not need a blank page. Your release notes already contain the facts; the work is turning them into an honest, human launch.
If you ship on GitHub, your most recent release is the natural launch artifact. The release notes already say what changed, what the version is, and often why it matters. That is your raw material. The job is to translate those facts up a level: from what shipped to what a stranger can now do, and from a changelog tone to a builder-sharing-work tone. Start from the release, not from a void, and the draft comes much faster.
A practical move is to let your release-marketing tool draft the title and body from the release, then make it yours. S2P reads the GitHub release and can produce a Show HN-shaped draft - a plain candidate title and a top-comment body with the what, the why, and a spot to name the honest limitation. You then rewrite it in your own voice, add the real story of why you built it, and submit it by hand. The tool removes the blank page; you supply the humanity the channel demands.
The honest framing matters: a draft is a starting point, not a finished Show HN. The posts that do well are unmistakably human, so the value of automation here is speed to a first draft and never the submission itself. Use the draft to beat the blank page, spend your saved time on the parts only you can write, and keep the actual posting deliberate and personal.
Show HN draft skeleton (from a release)
Title:
Show HN: A tool to post GitHub releases to social media
Top comment:
Hi HN. I built S2P because every time we shipped a release, the
announcement died in GitHub and I never got around to posting it.
It watches your GitHub releases, drafts channel-native posts
(LinkedIn, X, Bluesky, Discord, and more), and routes them for
approval before anything goes public.
What it does NOT do yet: [name a real limitation here].
I would love feedback on [one specific, concrete question].FAQ
Questions this article answers
What is a Show HN?
Show HN is a category of Hacker News post for sharing something you built that people can try right now, such as a tool, site, or library. The convention is that it is your own work, it is reachable without a waitlist or hard paywall, and you are genuinely open to feedback from the community.
What makes a good Show HN title?
A plain, specific description of what the thing is, using the Show HN: prefix and no superlatives. Something like Show HN: A tool to post GitHub releases to social media works because a busy engineer understands it in two seconds. Clever or vague titles get scrolled past or flagged.
When is the best time to launch on Hacker News?
Weekday mornings US time generally give the most runway, since the post has the American workday and European afternoon to gather early upvotes. Avoid late Friday and weekends. Timing improves your odds but never guarantees the front page, which has a real element of luck.
Can I automate posting to Hacker News?
You should not auto-blast Hacker News the way you might cross-post to LinkedIn or X, because the community values deliberate, human submissions and will flag generic launch spam. A tool like S2P can draft a Show HN title and body from your release to beat the blank page, but you submit by hand, as yourself, and S2P does not auto-submit to Hacker News.
Should I mention pricing in a Show HN?
Keep it honest and minimal. The top comment should be about the work, not the pricing page. It is fine to state plainly that there is a paid plan when asked, but lead with something people can actually use, and avoid putting a paywall or signup wall in front of the link.
What is the biggest mistake makers make on Show HN?
Writing like a press release. Marketing language, buzzwords, and hype copy signal that you do not understand the audience and get downvoted quickly. The fix is to write like a builder sharing work: specific, honest about limitations, and present in the thread to answer every comment.
Related guides and pages
Where to go next
Hand-picked pages that go deeper on the workflow, channels, and tooling covered above.
