A startup launch is often imagined as a curtain rising. Before it, secrecy and preparation. After it, the market delivers a verdict.
Real launches are smaller and more useful. You show an unfinished truth to a particular group, observe what happens, repair the product, and show it again. If the right width is unclear, compare a closed beta, invite-only release, open beta, and public launch by consequence and learning value.
Do not save every unanswered question for the largest audience you can reach.
Decide what this launch must teach
“Get attention” is not a complete goal. Attention from whom, followed by what action, to answer which question?
A launch can test whether:
- a painful problem exists for a named user;
- the promise is understood;
- a stranger can reach the first useful result;
- the result is valuable enough to repeat or pay for;
- one acquisition channel brings plausible users;
- the product and team survive a burst of public use.
Choose one primary question. The product, audience, channel, and measurement should all serve it.
Product Hunt’s launch preparation guide recommends measurable goals tied to the company rather than treating leaderboard position as the only result. That principle applies to every channel.
Launch one: the problem conversation
The first launch may have no public URL. Put the problem in front of people who do the work.
Ask about the last time it happened, the current workaround, who felt the cost, and what they tried. Show a sketch or rough workflow only after you understand the existing behavior.
You are not asking people to certify the idea. You are looking for a concrete job, urgency, and an initial group willing to continue the conversation.
Use the customer interview method to keep praise and hypothetical intent from becoming false demand.
Question: Does this problem exist in the form we believe? Audience: People who recently experienced it. Useful signal: Specific past behavior and a commitment to another step.
Launch two: the concierge result
Deliver the promised result manually for one or two users. Use a spreadsheet, a script, a call, or a rough internal tool. The user should receive real value even if the machinery behind it is embarrassing.
Paul Graham’s essay on doing things that do not scale explains why founders often need to recruit users and perform parts of the service by hand. The point is not permanent heroics. It is to learn what the eventual product must make reliable.
Write down every manual step, exception, missing input, and moment where judgment was required. Charge when the exchange can be honest. A manual paid result often teaches more than an automated free tour.
Question: Can we produce a result somebody values? Audience: One or two high-intent users. Useful signal: Real work completed, time or money committed, and another use requested.
Launch three: the narrow product
Turn the repeatable center of the manual service into the smallest product a user can operate.
Small does not mean careless. The product may lack integrations, themes, exports, and automation. It may not lose a user’s data, expose another account, charge twice, or trap somebody without recovery.
Paul Graham’s release-early advice makes this distinction: users can tolerate a minimal first version more readily than a buggy one.
Recruit a handful of users directly. Sit with them or watch the session. Fix the first point where they cannot continue without founder explanation. The first-ten-users guide provides the working rhythm.
Question: Can the intended user reach value through the product? Audience: Five to ten recruited users. Useful signal: Independent completion, return, payment, or a request to use it in real work.
Launch four: the controlled production beta
Move from friendly observation to the real public system: real domain, clean accounts, real inboxes, production data boundaries, and a controlled payment when relevant.
Do not announce broadly yet. Invite enough people to create varied state without overwhelming the team. Make the product public only to the degree the test requires.
Run the website launch readiness checklist and AI-built app production checklist. Test authentication, authorization, transactional email, backup restoration, billing, destructive actions, logging, support, and rollback from outside the founder’s browser.
Question: Does the promise survive production conditions? Audience: A small invited cohort using the live system. Useful signal: Completed journeys with known failure and recovery rates.
Launch five: the focused community
Choose a room where the problem is already understood. This may be an industry group, a local network, a technical community, a professional forum, or direct outreach to a carefully chosen list.
Join the conversation before asking for attention. Follow the community’s promotion rules. Explain what the product does in one sentence, why you built it, what remains rough, and what kind of feedback would change the work.
YC’s Kat Manalac advises founders to get basic products into potential users’ hands quickly and notes that focused communities can produce valuable early feedback before a press launch. Her YC office-hours discussion also warns that press is not a sustainable acquisition strategy.
Use the launch-channel guide rather than posting the same pitch everywhere.
Question: Can we recruit more of the same promising user? Audience: One community concentrated around the problem. Useful signal: Qualified attempts, completed jobs, useful objections, and returns after the launch post fades.
Launch six: the public platform
Hacker News and Product Hunt can produce sharp attention. They are not interchangeable audiences, and neither is a slot machine.
For Hacker News, make the product available to inspect. State what it does, supply technical detail, explain what is different, and participate candidly. The official Launch HN instructions emphasize access, transparent pricing, plain explanation, and an open invitation for feedback.
For Product Hunt, prepare the product page, maker comment, media, pricing, support coverage, and a measurable goal. Its current launch guide frames the platform as both distribution and feedback, and allows products to launch again after significant iterations.
Do not ask friends to perform fake enthusiasm. Do not hide access requirements. Do not change prices or promises midstream without explanation.
Question: Does the product and explanation hold under broader scrutiny? Audience: The selected platform’s actual community. Useful signal: Behavior by plausible users, repeated questions, technical failures, and durable use after the ranking ends.
Launch seven: the useful public source
The product launch and the search launch are different clocks.
Publish stable pages that answer the questions people ask before using the product: what it does, who operates it, how pricing works, what data it handles, how to get help, and how important workflows behave. Add focused guides drawn from real support and sales conversations.
Make those pages reachable through ordinary links, render essential facts in HTML, use coherent canonical URLs, and include intended public pages in the sitemap. The SEO and AI-search guide covers the shared foundation for people, search engines, and agents.
Search visibility rarely arrives as a launch-day spike. It compounds when the public source remains accurate enough to earn retrieval, citation, and links.
Question: Can somebody find and verify the product without the founder present? Audience: Future users asking durable questions. Useful signal: Qualified discovery, useful landing-page behavior, citations, and support questions answered by maintained pages.
Launch eight: the meaningful iteration
Launch again when something material changed: a new audience, capability, platform, business model, proof point, or solved limitation.
Do not disguise a color change as a rebirth. Explain what you learned, what changed, and why the update matters to this audience now.
Repeated launching is not repeated shouting. Each launch should carry a stronger product, a clearer claim, or a new question. Keep the people who cared during earlier launches informed without treating their inbox as property.
Product Hunt documents launches from companies that returned with significant iterations, while YC’s shipping advice treats release as an operating rhythm rather than a single permission ceremony. The durable advantage is not more launch days. It is shorter distance between evidence and change.
Know the line between rough and dangerous
Launch with incomplete settings, narrow templates, manual support, sparse integrations, and a plain visual system when those limitations are honest.
Stop or narrow the launch when:
- one user can reach another user’s private records;
- payment and entitlement can disagree;
- data can be lost without a tested recovery path;
- identity or account recovery is unsafe;
- the core result broadly fails;
- the team cannot observe or contain consequential errors;
- the public promise materially misstates the product.
The vibe-coded app launch guide provides a consequence-based boundary. Perfection delays learning. Preventable harm destroys the permission to keep learning with users.
Prepare one launch card
Before each launch, write:
Question: What must this exposure teach? Audience: Who can answer through real behavior? Promise: What result are we making? Access: What can they actually try? Must-work path: Which journey cannot fail safely? Stop conditions: What pauses the launch? Primary signal: Which behavior changes the next decision? Owner: Who watches product, support, and communication? Follow-up: When will we review the evidence?
Keep the card beside the launch-day runbook. It prevents a vague desire for attention from replacing the purpose of the launch.
Judge the launch after the traffic leaves
Within two working days, reconstruct the timeline. Separate audience, understanding, reliability, demand, and retention. Contact the strongest users and a few who stopped. Choose one product change, one reliability change, and one question to test.
The launch retrospective template makes this review concrete.
A quiet launch that identifies a painful problem can be successful. A crowded launch that produces no retained user can be noise. A broken launch can still teach, provided nobody was harmed and the team records the failure honestly.
Launch before the product feels grand. Do not launch before its important promises are true. Then use what happened to earn the next launch.