Dark Launches are a continuous delivery practice, which releases new features to a subset of your end-users and then capture their behaviors and feedback. They enable the team to understand the real-life impact of these new features, which may be unexpected for users in the sense that no users asked for them. It is one of the last steps for validating a product/market fit for new features. Rather than launch the features to your entire group of users at once, this method allows you to test the waters to make sure your application works as planned before you go live.

This is a feedback loop practice, which allows the team to get prompt feedback from real-life use of their changes. Dark launches provide safety by limiting the impact of new features to only a subset of the users. It allows the team to build a better understanding of the impact created by the new feature and the ways the users would interact with it. Often novel ways of interaction can surface, ways which were not initially envisioned by the team. This can be both positive and negative and the limited availability allows the team to draw conclusions from the real-life use and decide if the feature will be made widely available, further developed or discontinued.

The biggest risk to consider before going live is how your users will react to and navigate through your application. Before you launch, ask yourself three questions:

1. Are your users able to find the new feature?
2. Are they aware of the change?
3. Do they even need to know about it?

Once you’ve answered these questions and decided it’s time to go live, it should be a walk in the park — assuming all your findings during the first steps were positive. In most cases, all you have to do to go live is simply disable the old functionality of the feature you wrote. This can either be done by removing the old code or by disabling it in the configuration.

After you’ve gone live, monitor the behavioral changes of your application and your users to see whether the deployment was a success. If everything is going well, give yourself a pat on the back! Most of the time, though, it’s not quite that simple. You’re never 100 percent positive the application is working correctly, so you’ll want to keep the old code available or running for a few days or weeks to ensure there are no bugs that pop up.

Related Practices

• Feature toggles are an enabling practice, which allows for Dark Launches to be implemented in existing products.
• Dark Launch is similar to A/B Testing in the sense that it is only exposing a part of the population to the new feature, but unlike A/B Testing, the new feature can and is typically a completely new feature and not just a small tweak of an existing one. Additionally, A/B Testing improves the product performance in terms of getting business outcomes from an existing feature, while Dark Launches explore the possibility to extend the market by adding new features.
• Dark Launch is similar to the Canary Release as they both expose only part of the population to a feature. The Dark Launch is focused on understanding the way users will react and use the new feature, while Canary Release is really focused on the technical performance of the changed product or the individual feature (if using it can be isolated in the architecture).