What is our primary use case?
LaunchDarkly is primarily used for continuous delivery and targeted rollouts. It allows us to test changes on small segments of real traffic before rolling them out widely, enabling experimentation on a small segment of users for any feature before rolling the feature out to a wider audience. Rollbacks become very simple if we need to roll something back and change our experimentation, which reduces our stress and helps with our fire drills.
Recently, we launched a feature where we allowed users to upload documents using a new third-party vendor called files.com. This rollout had several moving parts to it, and since it was a new feature, we wanted to experiment with a targeted set of users first. We only rolled it out to one percent of our existing user base. We found an issue during the rollout, and we discovered a bug that we did not encounter during testing. We quickly flipped the flag back, fixed the issue, put the experimentation out again, and then eventually launched it to our entire user base.
Previously, we used to do deployments based on a cadence. We had to do thorough QA testing for every single change or commit that was rolled into the deployment. With this new cadence, we are doing continuous deployments, and we are putting a lot of experimentation behind LaunchDarkly flags. If we find something, we quickly flip that flag back without having to roll back the entire deployment. The cadence has changed from doing a deployment once a week to continuous deployments.
What is most valuable?
Structured experimentation with LaunchDarkly gives us compound time savings and confidence to quickly build features. The UI is pretty intuitive, which makes it very easy to manage any kind of A/B test. That is primarily what we use it for.
LaunchDarkly allows us to do structured experimentation and safe deployments in a single unified workflow. Running A/B tests is pretty smooth, and the UI is very intuitive, so those are the best features.
The ease of use and the UI being intuitive are valuable aspects. Quickly flipping the flags, knowing what belongs where, and having that part be pretty intuitive have been useful.
Customer support is highly rated, particularly for its technical depth and efficacy, and how quickly they respond back if we have any queries. We had a couple of queries to them in the past, and they were diligent about it and got back to us quickly.
LaunchDarkly has positively impacted our organization by transforming how we deploy software and manage risk. We are now able to separate code from release, which significantly reduces our deployment risk. Previously, if something went wrong, we would have to roll back our entire release, so now that is decoupled. Even the non-technical product teams can easily turn on and turn off features, so we do not have to rely on the product team communicating with the engineering team and waiting for them to get that done. It has empowered our product teams, and it has accelerated our CI/CD pipeline, so we can do more frequent code merges and run more experimentation.
What needs improvement?
There is definitely a learning curve for new team members when it comes to organizing and cleaning up flags in LaunchDarkly. Once a project scales, managing multiple flags can become cluttered, and performance could degrade if you do not stay on top of deprecating and maintaining the old flags. Having an easier way to do that would be pretty useful.
In a microservices world, managing flag state changes and propagation across complex or heavily distributed backend architectures can introduce latency or consistency challenges. While the UI is clean and pretty intuitive, tracking conditional flag modifications across large engineering teams requires more robust historical audit logging.
For how long have I used the solution?
LaunchDarkly has been used for the last four years.
How are customer service and support?
Customer support is highly rated, particularly for its technical depth and efficacy, and how quickly they respond back if we have any queries. We had a couple of queries to them in the past, and they were diligent about it and got back to us quickly. Based on my limited interaction, I would give customer support a nine.
Which solution did I use previously and why did I switch?
Before LaunchDarkly, we used to manage our configs in app config. We had static configurations all around that we had to constantly change. There were engineering bottlenecks, so product teams and non-technical stakeholders could not just toggle features. We lacked targeted audiences with that, meaning we could not target a particular user base. It was always a database, creating overhead and performance latency. Our custom app config solution required continuous queries against the database where we had stored our config and heavy caching to reduce the latency, which were some of the difficulties that LaunchDarkly has helped us resolve.
Which other solutions did I evaluate?
When comparing LaunchDarkly to alternative solutions, it stood out because it had advanced multivariate target rules. Lighter tools often limit teams to simple on/off or percentage-based rollouts, while LaunchDarkly allowed us to build highly complex nested and contextual targeting rules based on user segments, device types, or custom metadata attributes, which are very useful for our experimentation. It has centralized control and audit trails, providing robust, enterprise-ready role-based access controls and explicit approval workflows. The deciding point that ultimately drove the decision was automated real-time delivery paired with instant kill switches that allow for millisecond-range propagation.
What other advice do I have?
Regarding LaunchDarkly's AI capabilities, there are things that it does pretty well. It has strict model restrictions where administrators can flag LLMs as restricted across an organization. It has decoupled runtime safety with kill switches. Prompt text and system instructions and parameters live in LaunchDarkly rather than hardcoded in files, allowing security teams to instantly deploy an emergency config change or activate a kill switch if an AI agent begins producing some kind of hallucination or unsafe output to reduce the blast radius.
There are some areas of friction and technical risk. This non-human identity and service account overhead means that automating AI deployments via CI/CD requires service accounts. Managing these non-human identities requires strict privilege access management integration to prevent API key leaks or exposing critical data for runtime AI flags.
About LaunchDarkly's accuracy and reliability, it is important to clarify that it does not generate AI content itself. It acts as an operational control plane and a feedback loop. Things that it does really well are targeted rollouts for AI, advanced AI A/B testing, native online evaluations and LLM judges. However, it has limitations such as non-configurable out-of-the-box settings. While custom rubrics are supported, the initial setup of out-of-the-box judges offers limited granular tuning. Teams with highly specialized domain needs must invest time into coding custom evaluation prompt wrappers, which is something that we had to do.
We have been working with several different AI agents as part of our experimentation with LaunchDarkly. It has helped us quickly launch those experiments. Some other critical AI challenges it has helped us solve include safely testing different kinds of prompts in production instead of relying on staging environments completely. LaunchDarkly allows us to run different canary tests, and we can tweak prompts on the fly to see which one works better. It has allowed us to control some hallucination and latency outages, so if a newly deployed system prompt or model starts causing hallucinations or has access latency, we can use an instant kill switch or roll back the AI config in milliseconds before it impacts our broader user base. Additionally, it helps with mitigating model vendor lock-in, allowing us to utilize multivariate flags to easily swap traffic between different providers such as Opus or Sonnet without changing application code. It is something similar to what Bedrock provides in AWS, allowing us to seamlessly optimize for cost, speed, and accuracy.
For our CI/CD code management, GitLab is our primary tool for that. In terms of observability and monitoring, we use Datadog and integrate with that. Feature flags are also directly linked to Jira issues, allowing product managers to track deployment status straight from the ticket, with the status of the flag automatically updating as a feature moves from development to full production release. We also have dedicated Slack channels that receive automated real-time alerts when a flag configuration is changed, turned on, or turned off. All these integrations make our process smoother.
Understand your use case before implementing LaunchDarkly. LaunchDarkly is pretty good at complex flag management, but if your use case is simple flag management and you do not really want to scale to too many users, then it might be overkill for you. A rating of eight out of ten reflects a balance of strong functionality alongside specific operational hurdles, namely the lack of management for stale flags and an aggressive scaling-based cost structure.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Disclosure: My company does not have a business relationship with this vendor other than being a customer.
