Soft launch: how to release your product quietly first

Wikipedia defines a soft launch as a preview release of a product or service to a limited audience prior to the general public, often used to gather data or customer feedback before an official release. Restaurants call it a soft opening: the kitchen serves friends and neighbors for a week before the grand opening, so the first real critic does not meet a cook who has never used the new oven.

For software, the limited audience can be:

• a waitlist you invite in small batches
• one community, such as a subreddit, a Slack group or a forum you already take part in
• one country or one language
• existing customers of another product you run
• people who reply to a single post on your own social account

The common point is control. You choose who gets in, how many, and when.

A hard launch is the opposite: everything at once. Public announcement, launch platforms, newsletter, press, social posts, all on the same day. Here is how the two compare.

You rarely have to choose. Most good launches are a soft launch followed by a hard launch. The soft phase gives you a working onboarding, a few testimonials and real numbers. The hard phase turns those into reach.

Run one if any of these is true:

• Your onboarding has never been used by a stranger. Friends who watched you build it do not count.
• The product handles money, data or accounts. A billing bug in front of 50 users is a support ticket. In front of 5,000, it is a refund wave.
• You do not know which message works. A small release lets you test two descriptions on real people.
• You need proof for the public launch. A quote, a usage number or a before and after screenshot makes a launch post far more convincing.

Skip it, or keep it to a few days, if the product is tiny, free and has no account system. A browser extension with one button does not need a month of private testing.

Week 1: invite the first 20 people by hand

Paul Graham's essay Do Things That Don't Scale puts it plainly: the most common unscalable thing founders have to do at the start is to recruit users manually. Do that now. Send personal messages to 20 to 30 people who have the problem you solve. If you need a list, start with our guides on finding beta testers and early adopters.

Watch three things: where people get stuck in signup, whether they reach the first useful result, and what they ask you that the product should have answered.

Week 2: fix the first-session problems

Do not add features yet. Rewrite confusing copy, remove a step from onboarding, fix the bugs people actually hit. Then invite the next batch of 30 to 50 people and see if the same problems repeat. If they do not, your fixes worked.

Week 3: open one channel

Pick a single public channel with a friendly, technical audience. For developer tools, a Show HN post on Hacker News fits well: the Show HN guidelines ask for something people can actually try, which is exactly what a soft-launched product is. For other niches, one community post where you are already known is enough.

Measure signups, activation (the share of signups who reach the first useful result) and replies. Keep a list of every objection.

Week 4: decide

At the end of the month, look at the numbers and answer one question: would a stranger who lands here today understand the product and get value in the first session? If yes, schedule the hard launch. If not, repeat weeks 2 and 3.

For mobile apps, both stores have built-in soft launch tools. Apple's TestFlight lets you add up to 100 internal testers from your team and invite up to 10,000 external testers. Google Play offers internal, closed and open testing tracks: internal testing reaches up to 100 testers for quick checks, and closed testing lets you widen the group before release. Games often go one step further and release in a single country first.

For web apps and SaaS, use feature flags. Martin Fowler's article on feature toggles describes release toggles, which let you ship code to production while keeping a feature hidden, and canary releasing, where a small share of users sees the new version first. In practice, a simple invite code, a waitlist or an allowlist of email addresses is often enough.

For the waitlist itself, a coming soon page with one clear sentence and an email field does the job.

• Inviting too many people at once. If 500 people arrive on day one, you cannot talk to them. That is a hard launch without the reach.
• Only inviting friends. They are polite. You need people who would pay for a solution to the problem.
• No success metric. Decide before you start what "ready" means, for example: 40 percent of new users complete onboarding without help.
• Staying soft forever. A soft launch is a phase, not a strategy. After four to six weeks, most products learn more from a public launch than from another private batch.
• Burning your public launch. Keep the product off big launch platforms during the soft phase. A first impression on a platform like Product Hunt is hard to redo.

When your numbers say ready, reuse everything you collected: the clearest description from your tests, two or three user quotes, a screenshot of the result people liked most. Then plan the public day with our product launch strategy and, if it fits your audience, a Product Hunt launch.

You can also list your product on MegaLaunch as part of that public day. A listing works best once the soft launch has shown you which one-line description people actually understand.