My main use case for LaunchDarkly is feature flagging and gradual rollouts. Instead of releasing a new feature to all users at once, we can first enable it for internal users, then for a small group of customers, and only later roll it out to everyone. When we released a new feature, we first turned it on only for internal users. After that, we enabled it for a small percentage of real customers, which helped us test that feature in production without taking too much risk. If something went wrong, we could simply turn the flag off in LaunchDarkly without doing a full rollback. We use flags for gradual deploying and testing, then rolling out. For example, we enabled a feature, tested it in a specific environment, then turned off this flag.
My main use case for LaunchDarkly involves dark releases on production and feature flagged features delivered to customers. I use LaunchDarkly to test new releases on staging and sandboxes, and later deliver it to production darkly. I test it, verify that the dry run is fine, and afterwards release it. I have additional thoughts on how LaunchDarkly fits into our process by splitting our platform into models using feature flags and delivering it meaningfully.
Staff Software Engineer at a wholesaler/distributor with 10,001+ employees
Real User
Top 10
Oct 22, 2025
Currently, my main use case for LaunchDarkly is as a consumer. The application that I'm using uses LaunchDarkly as feature toggles. We toggle our flags on and off depending on what environment they're in, and depending on what state of the application's development lifecycle is. I can give a specific example of how I use LaunchDarkly for feature toggles in my application. We've got a set of features that we're keeping hidden behind a set of feature toggles, specifically based on how we're allowing users to log into our application. When the feature toggle is on, the functionality allows the user to access the new identity provider that we're using. When the feature toggle is off, it's using our old, previous functionality for our identity provider.
We use the solution for risk-free releases, allowing us to control the blast radius when launching content to our customers. We also use it for targeted experiences, enabling us to reach specific customer segments with various features as they are rolled out. However, the company's main use case was extensive A/B testing to conduct experiments.
We built a powerful e-commerce platform and heavily used LaunchDarkly to launch features behind a flag. This allowed us to implement trunk-based development, significantly improving our development speed. We could continuously deploy everything behind a flag and enable features only when ready, which was incredibly helpful. There are certain features we need to keep behind a flag. Typically, there are two ways to do this: using a property file or using LaunchDarkly. With property files, we had to deploy the feature in a lower environment, update the property, and then restart the server. LaunchDarkly, on the other hand, offers real-time changes and the ability to disable features if issues arise in production. This real-time capability is extremely beneficial.
LaunchDarkly is the runtime control platform for the AI era. It includes two solutions: CodeControl and AgentControl. CodeControl helps teams ship AI-generated code safely with feature flags, progressive rollouts, observability, experimentation, and automatic recovery—so they can move fast without losing control. AgentControl helps teams manage AI agents in production by configuring prompts and models, monitoring behavior, and taking action in real time without redeploying. Together, they...
My main use case for LaunchDarkly is feature flagging and gradual rollouts. Instead of releasing a new feature to all users at once, we can first enable it for internal users, then for a small group of customers, and only later roll it out to everyone. When we released a new feature, we first turned it on only for internal users. After that, we enabled it for a small percentage of real customers, which helped us test that feature in production without taking too much risk. If something went wrong, we could simply turn the flag off in LaunchDarkly without doing a full rollback. We use flags for gradual deploying and testing, then rolling out. For example, we enabled a feature, tested it in a specific environment, then turned off this flag.
My main use case for LaunchDarkly involves dark releases on production and feature flagged features delivered to customers. I use LaunchDarkly to test new releases on staging and sandboxes, and later deliver it to production darkly. I test it, verify that the dry run is fine, and afterwards release it. I have additional thoughts on how LaunchDarkly fits into our process by splitting our platform into models using feature flags and delivering it meaningfully.
Currently, my main use case for LaunchDarkly is as a consumer. The application that I'm using uses LaunchDarkly as feature toggles. We toggle our flags on and off depending on what environment they're in, and depending on what state of the application's development lifecycle is. I can give a specific example of how I use LaunchDarkly for feature toggles in my application. We've got a set of features that we're keeping hidden behind a set of feature toggles, specifically based on how we're allowing users to log into our application. When the feature toggle is on, the functionality allows the user to access the new identity provider that we're using. When the feature toggle is off, it's using our old, previous functionality for our identity provider.
We use LaunchDarkly for managing feature flags. It helps manage the keys to control what users view on our screens.
Our developers are using LaunchDarkly. I am using it to turn on features.
We use the solution for risk-free releases, allowing us to control the blast radius when launching content to our customers. We also use it for targeted experiences, enabling us to reach specific customer segments with various features as they are rolled out. However, the company's main use case was extensive A/B testing to conduct experiments.
We built a powerful e-commerce platform and heavily used LaunchDarkly to launch features behind a flag. This allowed us to implement trunk-based development, significantly improving our development speed. We could continuously deploy everything behind a flag and enable features only when ready, which was incredibly helpful. There are certain features we need to keep behind a flag. Typically, there are two ways to do this: using a property file or using LaunchDarkly. With property files, we had to deploy the feature in a lower environment, update the property, and then restart the server. LaunchDarkly, on the other hand, offers real-time changes and the ability to disable features if issues arise in production. This real-time capability is extremely beneficial.