Senior Software Engineer at a tech vendor with 1,001-5,000 employees
Real User
Top 20
Aug 11, 2026
I primarily use LaunchDarkly for rollouts, having flags, and putting my feature and code behind the flags. I have multiple codes that I need to organize in different branches, and it is better to put those behind different flags so we can turn them on and off and test them in required environments. I work with Java SDKs and Go SDKs to integrate LaunchDarkly, which really helps when dealing with a complex workflow and allows me to turn off a flag for a feature if it is not working well. With LaunchDarkly, we are using a lot of AI to ship our bulk of code, which helps us keep new changes behind the flags until fully tested, enhancing our day-to-day usage. We integrate monitoring tools like OpenSearch and Grafana with LaunchDarkly; these integrations are sufficient for our needs, and we use a common library built for across the organization to utilize LaunchDarkly flags and features.
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 delivers feature flagging and experimentation tools that enhance deployment speed and safety with its intuitive interface and real-time management capabilities, providing teams with the flexibility to toggle features effectively.LaunchDarkly empowers teams with advanced feature management, allowing for quicker and safer deployments via feature flagging and experimentation. Its intuitive interface simplifies the management of flags, toggling features on or off, and applying...
I primarily use LaunchDarkly for rollouts, having flags, and putting my feature and code behind the flags. I have multiple codes that I need to organize in different branches, and it is better to put those behind different flags so we can turn them on and off and test them in required environments. I work with Java SDKs and Go SDKs to integrate LaunchDarkly, which really helps when dealing with a complex workflow and allows me to turn off a flag for a feature if it is not working well. With LaunchDarkly, we are using a lot of AI to ship our bulk of code, which helps us keep new changes behind the flags until fully tested, enhancing our day-to-day usage. We integrate monitoring tools like OpenSearch and Grafana with LaunchDarkly; these integrations are sufficient for our needs, and we use a common library built for across the organization to utilize LaunchDarkly flags and features.
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.