Soft Launch

Method

A release that opens a feature quietly, with no announcement or advertising, and watches how the people who find it actually use it.

Why it exists

Launching used to be one day's work. Opening the feature and telling people about it were scheduled for the same morning. A press release goes out, 120,000 people get an email, ads start running, and the new feature appears on screen at the same hour.

That arrangement behaved worst exactly when something went wrong, because the largest possible audience meets the problem at the moment the largest possible audience is watching. A bug that keeps documents from saving under some condition surfaces in the afternoon and leaves two options. Roll it back and what you just announced no longer exists. Leave it and the first experience of every new arrival is that bug.

What gets wasted there isn't the feature. It's the publicity. A press release and a mass email can't be spent twice on the same people, and once spent there's no way to pull that audience back. So the only time that budget earns its cost is after the product is confirmed ready, which is a different question from whether the code is finished.

A soft launch separates the two acts. The feature opens first, and the decision about telling anyone gets made from what opening it revealed.

How to run it

Do the opening now and postpone the announcing. Five steps.

  1. Decide what you'll judge it on before you open. Write down the numbers and the passing bar ahead of the release date — something like 40 percent of people who use the feature coming back to it within three days, with an error rate under 0.5 percent.
  2. Decide the scope. Use a feature flag, a switch that turns a feature on or off while the code is already deployed, to enable it for 5 percent of users. Pick a boundary you can compare against later, like new signups or one pricing tier.
  3. Open quietly. No announcement, nothing in the release notes yet, no banner on the home screen. Hold that state for two weeks so only people who ran into it while clicking around are using it.
  4. Watch. Read the numbers from step 1 next to the support messages. Numbers report what happened and the messages carry why. Thirty messages read closely beat a dashboard nobody interprets. Keep a rollback path — the procedure for returning to the previous version — ready during the whole window.
  5. Pick one of three. Clear the bar and you attach publicity and move to general availability (GA). Miss it and you fix the gap and run another two weeks. Find almost nobody using it and you close it. Leave the third option off the list and this method turns into a normal launch with extra steps.

When it fits and when it doesn't

It fits when the building is finished and the reception isn't predictable. Not the state where you don't know whether the feature works — the state where you know it works and don't know whether anyone wants it. It earns the most when you're about to spend publicity you can't spend twice, and when the thing you're shipping leaves a long first impression, like a change to pricing.

Two neighboring methods have different aims. A canary release ships to a small group first to watch for errors and load, which is a technical safeguard. An open beta lets anyone in while labeling the product as unfinished. A soft launch neither labels the feature nor gathers an audience. The only thing it postpones is the publicity.

Four limits.

  1. With few users, two weeks tells you nothing. In a product with 20 signups a day, enabling it for 5 percent means fourteen people meet the feature in two weeks. That sample can't separate 40 percent from 25 percent, and treating it as if it could is worse than not measuring.
  2. Quiet is not secret. Competitors watch product pages and users post in communities, so using this to keep something hidden misreads it. What you're postponing is only the moment you say it first.
  3. You hold up two versions at once. While 5 percent see one screen and 95 percent see another, support answers and testing both double in scope. Every bug report now starts with working out which version the person was on.
  4. It becomes an excuse to not decide. Skip step 1 and there's no basis for judging, and a feature sits in soft launch for six months. Watching without a bar isn't watching; it's forgetting.

How it sounds at work

"Let's soft launch this one. We'll decide on the press release in two weeks, based on the numbers."

Proposing to separate the decision to open from the decision to announce.

"It isn't in the release notes yet. Right now only people who stumbled onto it are using it."

The silence is deliberate, which also means low support volume is expected.

"Two weeks in and reuse is at 22 percent. Let's fix the first screen before we tell anyone."

The pre-agreed bar wasn't met, so publicity waits and the work continues.

Pagedeck opened its document templates feature this way. Before release day Mia wrote down two bars: 40 percent reuse within three days and an error rate under 0.5 percent. Theo turned the switch on for 5 percent of new signups, and Ravi held the prepared email campaign for two weeks. At the two-week mark the error rate passed and reuse came in at 22 percent. Reading the support messages showed why: people picked a template and then closed the screen, unsure what to do next. The team fixed the first screen without announcing anything, ran another two weeks, and sent the email once reuse reached 41 percent.

What people get wrong

The most common reading is that this is how you ship something unfinished. "Opening quietly" sounds like a description of work you'd be embarrassed to show. But the only thing postponed here is publicity, and the feature opens complete. Open something half-built and the two weeks of numbers measure the state of the build rather than the value of the idea, and a decision made from those numbers can point the opposite way from the truth.

The other misreading is that watching without a bar produces a judgment on its own. Data accumulates, so it feels like looking at it later will settle things. In practice, with no bar written down, the same chart supports both the case for announcing and the case for waiting. The loudest person in the room ends up deciding, and those two weeks turn out to have been a delay rather than a decision. Writing the bar down beforehand costs ten minutes and is the only part of this method that can't be added afterward.

Easily confused with

TermVisible to usersHow it differs
Dark launchNot visibleTurns the code on without surfacing it, exercising server-side behavior only. The aim is measuring load and errors, so it produces no signal about how users react

Where to go next

  • Release

    see the whole sequence of shipping and the other approaches inside it

  • Hotfix

    compare the approach used in the opposite situation from the same family

Last updated 2026-09-16