LaunchDarkly

What do you like best about the product?

LaunchDarkly allows for controlled releases of features. I enjoy having control of features through feature flags. They allow us to turn features on and off and even test features without having to deploy. Rollout controls and targeting options are extremely helpful when deploying features gradually. Also allows for better development and operations collaboration by having more visibility of what features are turned on per environment.

What do you dislike about the product?

The only issue I’ve encountered is when you start to accumulate a lot of feature flags. There would need to be proper policy around reviewing/removing old flags.

What problems is the product solving and how is that benefiting you?

Less risk when releasing features. With LaunchDarkly we have the ability to gradually roll out features. Instead of pushing changes to everyone we can monitor and fix issues along the way. This allows teams to feel confident about deployments, increase stability and get features shipped quicker with better control of production.

What do you like best about the product?

What I like most about LaunchDarkly is the complete control it offers over when a feature is released. As a PM, I prefer rolling out features gradually in collaboration with the engineering team, rather than releasing something to all users at once. Using feature flags is very straightforward, and the ability to test features with specific users before a full rollout is highly beneficial. It also facilitates coordination between product and engineering teams regarding releases, as it allows you to decouple deployment from the actual release.

What do you dislike about the product?

Setting it up and understanding all the options initially requires some time and a learning curve. Additionally, team members who haven't worked with feature flagging before may need some time to get used to it.

What problems is the product solving and how is that benefiting you?

LaunchDarkly enables safer feature releases by allowing you to roll out features to users gradually. If something goes wrong, you have the ability to instantly turn off the feature. You can also use Launch Darkly to test features with specific customers and manage distinct experiences for different user segments. This simplifies the coordination of releases between product and engineering teams.

What do you like best about the product?

Split makes it easy to control who can use specific features. The best part for me is that we can release a feature without making it available to every user immediately. We can enable it first for internal users or a small group of users. After gathering feedback, we can gradually roll it out to more people. As a product manager, this is incredibly beneficial because I don't have to wait for another deployment just to change access settings. It also helps maintain alignment between the product, developer, and QA teams.

What do you dislike about the product?

When you have a large number of feature flags, the dashboard can start to look cluttered. Also, teams need to ensure they properly remove old flags.

What problems is the product solving and how is that benefiting you?

This helps mitigate risks associated with new releases. We use it to control who sees new features. It allows us to test features with specific users and instantly disable them if something goes wrong.

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.

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.

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.

LaunchDarkly has been used for the last four years.

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.

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.

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.

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.

Public Cloud

Amazon Web Services (AWS)

What do you like best about the product?

The best part about Launchdarky is how easy it is to set up and use. I’m able to integrate it with my backend, jobs, and applications in a consistent, seamless way. Managing multiple flags is also a breeze, which makes it simple to stay organized as things scale.

What do you dislike about the product?

The pricing can be somewhat challenging in a consumer-focused space because it’s based on MAUs.

If you’re B2B and have higher revenue per user, the pricing tends to work out well and feels more cost-effective.

What problems is the product solving and how is that benefiting you?

I don’t have to spend time building infrastructure for segmentation, A/B tests, or feature rollout controls.