How to Launch an Unfinished Product Without Losing Trust
Launch an unfinished product by saying plainly what it does today, what it does not do yet and what you want feedback on, in the first lines of the page and the post. Pick places that accept early work, keep the core path working, protect people’s data and money, and publish a short changelog so visitors can see progress. Do not charge for features that do not exist.
Which kind of unfinished is yours?
The word covers very different situations, and the right launch depends on which one you are in.
| State | Example | What to do |
|---|---|---|
| Rough but works | A habit tracker with plain styling and no export, but logging and streaks work | Launch, and list the rough parts |
| Works for one path only | A resume tool that formats one template and says so | Launch narrowly: name the one path and promise nothing else |
| Does not work yet | A landing page for an app that is not built | Do not launch as a product; collect interest honestly or post it as an idea |
Whether you should launch at all is a separate question, answered in should you launch before the product is ready. This page assumes the answer was yes and is about how.
How do you describe what works and what does not?
Put a status block near the top of the page and the first lines of the launch description, not in the footer. It has three parts: what the product does today, what it does not do yet, and the one thing you want to learn. Be specific. “Works on Chrome and Edge, not yet on Safari” is useful, and “still in beta” is a shield that tells a visitor nothing.
Status: early version, built [month]. Works today: [two or three concrete things]. Not there yet: [two honest gaps, and whether they are planned]. Please tell me: [one specific question you want answered]. The price today is [free, or what it costs]. If that changes, I will say so here and email people who signed up.
A visitor who reads that block knows what to expect before they click, so a missing feature stops being a letdown and becomes a known limit. That is what keeps trust when the product is rough.
Which places welcome early work?
- Show HN, with a condition. Its guidelines, read on 13 November 2026, say a Show HN needn’t be complicated or look slick and that the community is comfortable with early-stage work. They also say that if your work is not ready for users to try, you should not post, and that landing pages and sign-up pages are not Show HNs.
- BetaList. It features startups before launch or already live, with a review step and plans chosen before review, per its own agent-submission page. Check its submit page for what is free today.
- This board. Launch your product free with an honest description. It is ours and there is no queue. A published launch is final, so write the status block honestly before you press Publish and keep the live version of it on your own page.
- Store test tracks, for mobile apps. Apple’s TestFlight page says you can invite up to 10,000 external testers and test a build for up to 90 days. Google Play’s closed testing lets you share with a group you control, and for personal accounts created after 13 November 2023 a closed test of 12 testers for 14 days is required before production access.
Match the place to the state. A product that works for one path suits a community post that shows that path. A rough but working product suits a board and a Show HN. For a mobile app that is not yet in a store, a test track is the container that lets strangers use unfinished work legitimately.
How do you set up a feedback loop that works?
- Pick one place for feedback and say where it is: an email address, a short form or the comments on the launch.
- Ask the one question from your status block, and ask it again in every reply.
- Triage each piece of feedback into fix now, park for later or ignore, and write the reason in one line.
- Fix the top item that more than one person raised, then say so publicly. A visible fix teaches visitors you answer.
- Keep a list of what you parked, because the pile you ignore today will contain next month’s roadmap.
What must be protected even when the rest is rough?
Three things do not get an “early” discount. First, people’s data: if you store an email address or anything personal, say what you keep and why, and make sure it is not exposed. Second, money: never charge for a feature that does not exist, and if the product is free during the early version, say how that might change. Third, claims: do not list integrations, certifications or customers you do not have. A visitor forgives a missing button and does not forgive a false statement.
If the server cannot take a rush of sign-ups, cap them and say so, instead of letting the product fall over under the first visitors. A capped, honest page beats a broken one.
How do you show progress after launch?
Keep a short, dated changelog on the page, with one line per fix. It proves the product is moving and gives returning visitors a reason to look again. The changelog template has a layout. Update your status block as gaps close, on your own page, and point people there instead of posting a new launch. Announce again only when something a stranger would notice has changed, as the can you launch the same product twice answer explains. If you are still choosing what to build, the ideas board has plenty, and an idea you will not build yourself can be posted for free.
Frequently asked questions
Is it okay to launch a beta?
Yes, if you say what works, what does not and what you want to learn. A beta label alone tells visitors nothing. Be specific about limits, keep people’s data safe and do not charge for features that do not exist. Many places welcome early work, but Show HN still expects people to be able to try it.
Should I charge for an unfinished product?
Only for what exists today, and say so. Charging for features that are not built is a promise you may not keep. If you charge a low early price, state what it covers and whether it will change, and tell buyers before it does.
What should I put on the page about what is missing?
Name the gaps in plain words, near the top: what is not there yet and whether it is planned. “Not yet on Safari” is useful, while “still in beta” is not. Visitors treat a stated limit as honest and an unstated one as a defect.
Can I launch a landing page before the product exists?
Be careful. Hacker News’s Show HN rules say sign-up pages and landing pages are not Show HNs because they cannot be tried. A board is more flexible if the description states that nothing is built. If you only have an idea, post it as an idea instead.
How do I keep early users from leaving?
Reply to every message, fix what more than one person raises and say so in a changelog. People stay with an unfinished product when they see it improving and feel heard. Ask early users one question at a time, and thank them in public when a fix came from their report.
Written by Post your build ideas with AI assistance and edited for this site. Where a page names another product, the facts came from that product’s own pages on the date shown above; terms change, so check them before you rely on them. About the publisher.