Launch something small

A launch is an invitation

Launching means making a specific version discoverable and asking a specific group of people to do something with it.

It does not require a global event. Your first launch can be a repository ready for contributors, a prototype ready for five testers, a paid service ready for one customer, or a guide ready for readers.

Decide what is launching

Name the version and its boundary:

This release helps [person]
do [specific outcome]
by [current mechanism].

It includes:
- ...

It does not yet include:
- ...

The “does not include” list prevents an early release from pretending to be a mature product.

Choose the action

Every launch needs one primary invitation:

• try the demo;
• install the project;
• read the first chapter;
• submit an example;
• book a conversation;
• purchase the current version.

Do not give equal visual weight to six actions. A visitor should know what success looks like on this visit.

Assemble the evidence

Your public work already contains the launch material:

• the original problem from the project page;
• screenshots showing visible progress;
• decisions and lessons from weekly updates;
• feedback that changed the result;
• a concise demonstration of the current outcome.

Tell the story through these artifacts. Avoid claiming that a product is revolutionary, effortless, or for everyone.

Pick a relevant room

Launch where the intended people already gather. Product Hunt can create broad discovery for some technology products. Show HN values technically interesting work and direct participation from the maker. A focused subreddit or community may provide fewer views and better conversations. Your own email list or website gives you the most context and ownership.

Read the rules and culture before posting. Adapt the explanation to the room without changing the truth of the product.

Prepare for launch day

• Verify the primary path on mobile and desktop.
• Make setup or purchase instructions literal.
• Add a working contact or feedback channel.
• Prepare one screenshot or short demo that shows the real product.
• Test analytics only if you will use the data.
• Decide how you will respond to bugs and questions.
• Write down the evidence that will determine the next step.

Report what happened

After the launch, publish a retrospective. Include the goal, channel, actions taken, results, surprises, failures, and next decision.

Separate reach from value. A launch with modest traffic and three committed users may be more important than a large spike that produces no return.

Launch checklist

• [ ] The current version solves one understandable problem.
• [ ] The public page accurately shows what exists.
• [ ] There is one primary action.
• [ ] Setup, pricing, and limitations are clear.
• [ ] The launch channel contains relevant people.
• [ ] I can support the response I am asking for.
• [ ] I will publish what I learned after the event.

The launch is not the end of Build in Public. It is a larger feedback event inside the same loop: make, show, listen, decide, and continue.