What should my landing page have for a Show HN launch?

It should have a plain first line saying what the product does, a real example of input and output, and a way to try it without an account. Add links to docs and pricing in the nav, and a short section on how it works and what it gets wrong. Hacker News readers judge what they can inspect, so the page should look closer to documentation than to an ad.

Do I need a signup form for a Show HN?

No, and it usually hurts. The Show HN guidelines ask you to make your project easy to try, ideally without barriers such as signups or emails. Let people run the product on sample data first, then ask for an email when they want to save results or use their own data.

How do I stop Hacker News calling my AI product a wrapper?

Name the model you build on, then show what you built around it: the checks the system runs, what data goes where, and what it gets wrong. Put that on the page, not only in your replies. A reader who can see the extra work has less reason to guess there is none.

Should I show pricing on a Show HN launch?

Yes, even if pricing is not final. Say what is free today with a number, such as one project or a set number of runs a month, and say paid plans will come later. Hidden pricing tends to read as a catch to a technical audience.

Is a Show HN launch page different from a Product Hunt page?

Yes. A Product Hunt visitor often wants to see the product work quickly and looks for a free tier. A Hacker News visitor is more likely to open the docs, check where the data goes and ask which model runs it, so the page needs more depth and fewer claims.

What if my product cannot be tried without customer data?

Show one real recorded run of the product, unedited, and label it as a recording. Explain what a real setup needs and how long it takes. A one field waitlist is fine after that, as long as the page says plainly what happens next.

Show HN Launch: What Your Landing Page Needs

A Show HN launch landing page should read like good documentation, not like an ad. Put what the product does in plain nouns, a real input and output, a way to try it without an account, the model and data flow, the price and the known limits all on the first page someone clicks from the post.

This matters because Hacker News readers judge what they can check. They will open your docs, your pricing and your network tab before they read your headline twice. You know the hard parts of your product because you built them. The thread only sees the page, and if the page hides the hard parts, the comments will guess at them for you.

The Show HN that links to Get early access

Picture a tool that reads a Postgres slow query log and writes the indexes you should add. This is an example, not a real company. The post title reads Show HN: An AI that reads your slow query log and writes the index. The link goes to the homepage.

The hero says AI-powered database performance for modern teams. Under it plays a forty second video with music. Then three cards: Find, Fix, Ship. The only button says Get early access, and it opens a form asking for work email, company name and team size. The nav has Product, Company and Contact. There is no Docs link, no Pricing link and no line about which model runs the suggestions or where the query log goes. To try the real thing, you have to paste a database connection string into a screen that only exists after the form.

Behind that page sits a year of work. A set of 900 real query plans the team used to check the suggestions. A rule that refuses to suggest an index on a column with only three distinct values. A step that runs EXPLAIN before and after, so every suggestion comes with a cost number. None of it is on the page. The kind of top comment a thread like this gets within the first half hour is a question, not a compliment: is this just a model call with the EXPLAIN output pasted in? That line is an illustration, but every founder who has posted to HN knows its shape.

What an HN reader clicks before the headline

A Show HN visitor does not move down your page in the order you designed. Many read the comments first. On the page, the eyes go to the nav. Docs, to see if the product has real edges. Pricing, to see if there is a catch. A changelog, to see if anyone ships. Then the try path.

Hacker News is clear about this in its own rules. The Show HN guidelines say a Show HN is for something you made that other people can play with, and ask you to make it easy to try, ideally without barriers such as signups or emails. The same page says not to post landing pages. So the page you link is not really a landing page in the usual sense. It is the front door of the thing itself, and it gets judged that way.

Make the first screen look like a README

Here is the claim many launch guides will disagree with: for this crowd, the page that wins looks closer to docs than to a pitch. A literal first line, a real output under it, and headings like How it works, Limits, Pricing and Data. Most launch advice says lead with the benefit and save the details for later. On HN, the details are the benefit, because they are the proof that the work is real.

This is not an argument for an ugly page. Stature still counts, and a stranger still decides in seconds what kind of company you are. The difference is where that stature comes from. On a docs-shaped page it comes from type that is easy to read, code that is formatted well, and numbers that line up. A page full of glowing gradients reads as the opposite to this audience, which is the problem why AI startups look generic walks through in detail.

For the query log tool, the first line would read: Reads your Postgres slow query log and writes the CREATE INDEX statements, with the reason for each. Under it, one real slow query, the cost before at 48,210, the suggested index, the cost after at 312, and a grey line that says Skipped: index on orders.status, only 3 distinct values. Those numbers are invented. The skipped line matters most, because it shows judgement.

Answer the wrapper question on the page, not in the thread

If you are building on a model you did not train, say so on the page, and say which one. Then say what you built around it. Naming the model feels like admitting the product is thin. It works the other way. Once the reader knows the model, the only question left is what else is there, and you get to answer it in your own words.

A short How it works block that answers five things is enough:

Which model runs it, and whether you can swap it.
What runs on your side and what gets sent out, down to the field. For the example, the query text and the plan are sent, the row data never is.
What the system checks before it answers, such as the EXPLAIN step and the low cardinality rule.
What it gets wrong today. Partitioned tables, say, or queries over a certain length. Write it as a list, with dates.
How you tested it, with the size of the test set and when it was last run.

A visitor can check every one of those lines. That is the point. For a real dev tool in a crowded field, the Dualite case study is worth a look. Dualite is an AI builder that sat next to several tools that looked alike, and its site had to make the difference clear on sight. The study also notes the product was built for engineers while most signups came from non-technical builders, which is a good reminder to decide who your launch page is for before you post.

Let them run it before you ask for an email

The try path is the part most founders get wrong on launch day. A signup form before any result is the barrier the HN rules name. A Sign in with GitHub button that asks for access to private repos is worse, because this crowd reads the permission screen.

Give them a sample instead. For the query log tool, that is a button labelled Run on a sample log, which loads a public slow query log and shows the results in under ten seconds, no account. Next to it, a one line install command and a note that the CLI runs on your machine. Ask for an email only when someone wants to save results or connect their own database. If your product truly cannot run without the customer's own data, record one real run, unedited, and say plainly that it is a recording. If you are unsure whether a full sandbox is worth the build, the guide to interactive product demos has four questions that settle it.

Put the price and the docs in the nav

Hidden pricing reads as a trap to this audience, even when the real reason is that you have not decided. If you have not decided, say that, and say what is free today and what will stay free. A line like Free for one database, up to 10,000 queries a month, paid plans later, with no card is fine. A Contact us for pricing button on a Show HN is a quiet way to lose the thread.

Docs do not need to be complete. They need to exist and to be honest about where they stop. Four pages are enough for launch day: Quickstart, How it works, Limits and Data handling. Link all four from the nav, not the footer, and make sure the quickstart works on a clean machine. Someone in the thread will try it.

What the thread costs after launch day

Picture the founder in the thread. He posted at 7 a.m. Pacific. By 9 he has answered the model question four times, each time with three paragraphs about the eval set and the cost check. He pastes a link to a Google Doc with the architecture diagram. Someone asks where the query log goes, and he answers in a reply that sits fifty comments down. At noon he adds a Docs link to the nav that opens a Notion page. By the evening, the best explanation of his product is spread across a dozen replies most visitors never read. Every one of them was a line the page should have carried.

Launch traffic comes once, and people who bounce off a waitlist form rarely come back. Those who sign up still have to reach the first result: measured on SaaS and product led companies, activation runs 20 to 40 percent for most products. A launch that sends fewer people into that funnel starts behind.

The bigger cost is how the company gets read. A thread where the top comment calls you a wrapper is public, it ranks, and investors and engineers you want to hire will find it. Measured on AI companies, the Series A bar is now around 3.5 million in ARR, up from roughly one million three years earlier (Carta, Q1 2026). Perceived depth is part of how a company gets judged on the way there. A page that shows the depth gives you a better first read than any reply you write under pressure.

A docs-shaped launch page you can build this week

Rewrite the first line as a literal sentence: what it reads, what it writes, for whom. No adjectives.
Put one real input and one real output directly under it, with the numbers that prove the result.
Add a Run on a sample button that works with no account, and a one line install command if you have a CLI.
Write a How it works block that names the model, what is sent out and what is checked.
Write a Limits list with at least three honest entries and a date.
Put Docs, Pricing and Changelog in the nav. Give the free tier a number.
Ask a developer who has never seen the product to open the page cold, then list the questions they ask. Each one is a missing line.
Before you post, write your first comment with who built it, why, and what feedback you want. Link to the page sections, not to a doc.

If you would rather hand the page to a team that builds for engineers, this ranking of landing page design agencies for AI devtools compares studios on public criteria.

For founders in the US, UK and Europe, Studio Maydit designs the websites and products of AI companies, built in Framer, Webflow or custom code. A fixed-scope project takes three to four weeks, so if your Show HN is a month out there is still time to make the page carry the depth you built. If you want someone to read your page cold before you post it, book a 30 minute call with Studio Maydit.