Show HN rules: eligibility, demo access, and a useful first post

Check official eligibility first

The official rules require personally made, nontrivial work people can use. A landing page or signup-only page is insufficient, and blog posts do not qualify. Make trying the project easy, preferably without signup; this preference is not an absolute prohibition on accounts. Use the “Show HN:” title prefix. Do not ask friends to vote or comment, and do not assume a minor upgrade merits another submission.

Read the official Show HN page before posting. The examples and preparation steps below are editorial interpretations to help you apply those rules, not eligibility decisions from Hacker News.

Work through these eligibility examples

• A working image optimizer: visitors can upload a sample image and compare the output. This illustrates usable work with a clear experiment.
• An open-source parser: a repository includes installation instructions, sample input, and a reproducible command. Readers have a concrete way to evaluate it.
• A product waitlist: visitors can only leave an email address. Build a usable experience before considering Show HN.
• A development essay: an article explains your architecture but provides nothing to use. It does not become Show HN material merely because you wrote the software it describes.
• A small interface adjustment: changing a button or adding a theme does not establish a substantial new release. Assess what readers can meaningfully try that was unavailable before.

An account-based application needs special preparation. If accounts protect saved work, explain that purpose and provide a clear route into the product. A sample mode can help people assess the core idea before sharing personal information.

Make the demo easy to evaluate

Editorial checklist: open your link while signed out, follow the instructions literally, and try one realistic task. Check whether an empty dashboard leaves a newcomer stranded. Use a sample dataset, a short command, or an obvious first action to show the path.

• State what people can try in one sentence.
• Test the demo URL and any installation instructions.
• Show sample inputs and the expected output.
• Explain necessary account or environment requirements.
• Identify unfinished functionality and known limits.
• Provide a way to recover from common errors.

For a parser, “run this command against the included sample file” is clearer than “explore the repository.” For a browser tool, supply fictional data that demonstrates the main action without requiring someone to assemble their own dataset first.

Write a maker introduction

Use a factual title, such as “Show HN: A local tool that compares CSV schemas.” In your introduction, explain why you built it, what it does today, and one implementation decision worth discussing. Avoid a long feature inventory.

Editorial structure: “I built this after repeatedly checking schema changes by hand. The sample compares two fictional exports. It runs locally because I wanted to keep files on my machine. It currently misses nested JSON fields. I would appreciate feedback on how the differences are presented.” Replace those details with your own experience; do not claim a privacy property your implementation does not support.

A focused question makes feedback easier to act on. Ask whether the output is understandable or which failure case is missing, rather than asking readers to validate your entire business.

Respond and improve after posting

Set aside time to answer technical questions. When someone reports a failure, ask for the smallest reproducible example without requesting private data. Acknowledge a real limitation directly and explain any workaround.

Afterward, group feedback into access problems, unclear explanations, and product gaps. Fix the access problems first so future readers can try the work. Record changes in your project documentation. For broader planning, return to the side-project promotion guide and choose a next step based on what you learned.