Hacker News Launch Guide 2026: How to Post on Show HN Without Getting Flagged or Ignored

Hacker News can send 50,000 visitors to a landing page in six hours, or it can bury your post with two flags before anyone reads it. The difference almost never comes down to luck. It comes down to whether you understand the culture, the mechanics, and the unwritten rules that the HN community enforces ruthlessly.

This guide is for technical founders who want to actually use Hacker News as a launch channel, not just throw a link at it and hope. We will cover how the Show HN mechanism works, how to write a title and post that survives the first hour, when to submit, and how to handle comments without digging your own grave.

Why Most Show HN Posts Fail

The HN front page algorithm rewards early velocity: upvotes per minute in the first 30 to 90 minutes after submission. If your post does not get traction fast, it falls off the new page and effectively dies. Most Show HN posts fail for one of these reasons:

• The title reads like marketing copy instead of a plain description.
• The linked page is a landing page with no way to actually try the product.
• The founder is invisible in the comments, so the post looks abandoned.
• The submission gets flagged for looking like spam, self-promotion without substance, or a duplicate.
• Bad timing means the post launches into a crowded queue or a dead traffic window.

Understanding the flag-death spiral matters here. A single flag from a user with enough karma can suppress a post's ranking. Multiple flags can outright kill it, sometimes within minutes, regardless of upvotes. HN moderators (dang and the team) also manually intervene on posts that look like growth-hacked karma farming or coordinated voting. If your post smells like a marketing stunt, it will get killed even if it is technically a "show."

What "Show HN" Actually Means

Show HN is a specific submission category, not just any startup link. The guidelines are explicit: it is for something you have built that others can try right now. That means:

• A live product, tool, app, or open-source project.
• Something interactive, not a blog post, press release, or pitch deck.
• The submitter should generally be the creator or a core contributor.

If you submit a landing page with an email waitlist form as "Show HN: My New Startup," you are misusing the category and inviting flags. If your product is not ready to be used or tested in some real form (even a demo, a CLI you can install, a sandboxed environment), wait until it is.

Crafting the Title

The title is 90% of the click decision on Hacker News. HN users are allergic to hype. The best-performing Show HN titles are almost boring in their plainness.

The Formula That Works

"Show HN: [Product Name], a [plain description of what it does]"

Examples of titles that actually reach the front page:

• "Show HN: I built a tool that turns Postgres schemas into TypeScript types"
• "Show HN: Sqlite-backed job queue with zero dependencies"
• "Show HN: A CLI to diff Terraform plans in plain English"

Compare that to what kills posts:

• "Show HN: The Future of Developer Productivity"
• "Show HN: Revolutionizing how teams collaborate"
• "Show HN: We're disrupting the API monitoring space"

Avoid superlatives (best, first, revolutionary, game-changing). Avoid vague abstractions (productivity, collaboration, disruption). State the mechanism, not the promise. HN readers are engineers. They want to know what the thing does, not how it will change the world.

Length and Specificity

Keep titles under 80 characters where possible. If your product needs a category comparison to make sense ("like Stripe but for X"), that is fine, but only if it is accurate and not a stretch. False analogies get called out in the first three comments, and that thread becomes the story instead of your product.

The Post Body: What to Include

Show HN posts link to a URL, but you also get a text field for context. Use it. A good Show HN text block includes:

1. One sentence on what it does. No preamble.
2. Why you built it. A real reason, ideally a specific pain point you or your team hit.
3. What it's built with. HN readers care about stack choices and will ask anyway. Answer preemptively.
4. What's rough or unfinished. Naming your own limitations builds trust fast. It also disarms the inevitable "this doesn't handle X" comment.
5. A direct link to try it, ideally without a signup wall. If a login is required, say so and explain why.

Here is a real-shaped example:

Show HN: A local-first note app that syncs over IPFS

I built this because I wanted something like Obsidian that didn't depend on a company staying alive to keep my sync working. It's a Rust backend with a Tauri frontend, CRDT-based conflict resolution, and IPFS for the sync layer.

Known issues: mobile support is rough, and the initial sync can be slow on large vaults. Would love feedback on the CRDT merge logic especially, that's the part I'm least confident about.

Try it here: [link]. Source is here: [github link].

Notice the tone: plain, specific, slightly self-deprecating, and inviting technical scrutiny rather than avoiding it.

Timing Your Submission

Timing affects whether your post gets seen by enough early voters to build momentum before it falls off the new page.

Best Windows

• Weekdays, especially Tuesday through Thursday. Monday launches compete with a backlog of weekend submissions. Friday afternoon traffic drops off for the weekend.
• 6am to 9am Pacific time. This catches the US East Coast mid-morning and overlaps with European afternoon, giving you two waves of readers instead of one.
• Avoid major tech news days. If a huge story breaks (a major acquisition, an outage, a keynote), the front page gets dominated and your post gets buried under real velocity you cannot compete with.

Practical Timing Tips

• Submit it yourself. Do not use a service or ask someone else to submit on your behalf, it can look coordinated and increases flag risk if discovered.
• Do not schedule a big Twitter/X or LinkedIn push to coincide with the exact submission. A sudden influx of non-HN traffic voting patterns looks like brigading to the ranking algorithm and can trigger a flag review.
• Be online and available for the next 3 to 4 hours minimum. Do not submit and walk away.

Engaging Comments Without Digging a Hole

The comment section is where most Show HN posts actually win or lose. HN commenters are often the most technically rigorous audience you will ever face. Some will find real bugs. Some will nitpick your stack choice. A few will be needlessly harsh. Your job is to respond like an engineer, not a marketer.

Do

• Answer technical questions in detail. If someone asks how your conflict resolution works, actually explain it. Vague answers read as evasive.
• Thank people for finding bugs, then fix the bug and reply with the fix if you can do it fast. This has genuinely turned hostile threads into positive ones.
• Concede valid criticism. "You're right, that's a real limitation, here's how I'm thinking about it" reads far better than defending an indefensible design choice.
• Correct factual errors about your product calmly, with evidence (a link to docs, a code snippet), not indignation.

Don't

• Argue with downvoted comments. Arguing amplifies visibility of criticism and often looks defensive even when you are right.
• Use marketing language in replies ("we're passionate about," "our mission is"). It reads as inauthentic on HN specifically.
• Ask friends or teammates to comment in support without disclosing affiliation. If discovered, and it usually is, this triggers moderator action and can get the whole post killed.
• Disappear. A founder who vanishes after posting looks like they do not care about feedback, and karma-conscious users notice and downvote accordingly.

Avoiding the Flag-Death Spiral

Flags on Hacker News are a blunt instrument. A small number of flags from established accounts can sink a post regardless of upvotes. Common flag triggers to avoid:

• Vote manipulation patterns. A sudden burst of upvotes from new or low-karma accounts looks suspicious to both the algorithm and human moderators. Never ask for upvotes, ever, even indirectly.
• Reposting too soon. If your product was submitted before (by you or someone else) within the last few months, a repost can get flagged as duplicate spam. Check HN search first.
• Landing pages with no actual product. As covered above, this is the single fastest way to get killed.
• Overt promotional language in the title or body. Anything that reads like an ad copy trigger word (limited time, don't miss out, revolutionary) invites flags from HN's famously allergic-to-hype user base.

If your post does get flagged and killed, do not immediately resubmit. Email hn@ycombinator.com (dang and team read these) and ask politely what happened. Sometimes it is a mistake and gets reinstated. Sometimes you get useful feedback on why it was flagged. Resubmitting without understanding why almost always makes things worse.

What Happens If You Hit the Front Page

If your post gains traction, expect:

• A traffic spike that can hit your server hard if you have not load-tested. HN readers will hit your site directly, often bypassing CDNs if your setup is fragile.
• A wave of highly technical questions in the first hour, then a long tail of comments over the following 24 to 48 hours.
• Possible coverage pickup: tech newsletters and aggregator sites (like some startup blogs and X threads) often scrape the HN front page for stories, extending your reach beyond HN itself.
• Signups that convert lower than typical paid traffic but carry outsized credibility. "As seen on Hacker News" is a real trust signal for developer tools specifically.

Plan your infrastructure for a spike beforehand. Static landing pages, cached responses, and a status page you can point to if things slow down all help you survive the traffic without looking unprepared.

Coordinating HN With Your Broader Launch

Hacker News should rarely be your only launch channel, but it works best when it is not competing with your other channels for the same audience at the same moment. A common mistake is launching on Product Hunt, HN, and Twitter simultaneously, which spreads your available energy too thin to properly engage any single community. If you are running a multi-channel launch, staggering release across communities, and tracking which one is actually driving signups, matters more than hitting every platform on day one. Tools like welaunch.sh exist specifically to help coordinate that kind of staggered, multi-channel launch schedule so you are not trying to babysit five comment sections at once.

A Quick Pre-Submission Checklist

Before you hit submit, run through this:

• Product is live and usable without a waitlist or heavy signup friction
• Title is plain, specific, and free of hype words
• Post body explains what, why, stack, and known limitations
• You have not submitted this before (check HN search)
• Submission time is a weekday morning Pacific time
• You have 3 to 4 hours blocked to answer comments
• Server can handle a traffic spike
• No coordinated upvote or comment requests to friends or teams

Final Thought

Hacker News rewards genuine builders who show their work plainly and engage honestly with criticism. It punishes anything that smells like marketing theater. If you approach Show HN the way you would approach a technical code review, direct, specific, and willing to be wrong in public, you give yourself a real shot at the front page instead of the flag queue.

If you are coordinating a launch across HN, Product Hunt, and other channels at once, welaunch.sh can help you sequence the timing so each community gets your full attention instead of a diluted, simultaneous blast.