Share your experience using Plutora

My main use case for LaunchDarkly is to gate our new features behind the flags and to manage those flags via LaunchDarkly UI and portal and dashboard so that we can roll out different features properly tested on different environments and for different users and with different variations, with different configurations and settings.

One feature that we rolled out this way is a really big feature which was changing the product's whole flow and had to be rolled out to multiple markets, specifically to three different countries where our product is being used. Since it was a big feature, we had to get it behind the development first because it was in the development stage. We tested it out regularly with different variations, with different targetings, with different rule sets, using different LLMs and everything which was managed by LaunchDarkly. Then we launched it on staging, turning on the flag for staging to test it out there. When we rolled it into production, we selected a smaller customer country from the rules part for the launch to identify initial bugs or issues at a smaller customer base, eventually rolling it out and turning on the feature for bigger customers and bigger countries as well.

This is my main use case for LaunchDarkly; we create the flags there, manage them from there, and turn them on or off there. We have a whole dashboard where we can see who has made a recent change in the flag and what settings have been changed. If something breaks due to recent settings, we have an idea of what has been changed that caused it to not behave as required. Additionally, we have different variations, different rules in it, as well as a whole dashboard where we can look into it. It is really helpful to integrate it easily due to the flexibility that gives us confidence in LaunchDarkly.

LaunchDarkly has positively impacted my organization by providing flexibility and collaboration, as our company is divided into different squads. Every squad can collaborate on their flags, determining what needs to be turned on and for which squads, including variations and targetings.

I have witnessed improvements in collaboration through LaunchDarkly, as we have different variations for a flag that allows multiple squads to test different things simultaneously. Different squads use the same flag while testing various things, utilizing different variables, environments, variations, and targeting.

The best features LaunchDarkly offers include flexibility, a log about recent activities or who has done what, variations, targeting, and a single flag for different environments; these are the top most features that provide greater flexibility for LaunchDarkly.

Among those features, I rely on variations, the logs, and the rules the most; variations and the rules are particularly targeting the same thing, but these have significantly helped us.

I believe LaunchDarkly is working very well, but making it easier to integrate with code bases or providing an AI component that assists customers by understanding their code bases and supplying easy-to-integrate code snippets would be very helpful.

I have been using LaunchDarkly for almost around seven to eight months.

LaunchDarkly is stable.

Its scalability is good, as I mentioned previously, from the flexibility, scalability, and features points of view; it is good.

I have not felt a need to connect to customer support for anything, but I have heard from my other team members that customer support is great, really supportive, and collaborative. Their customer support success manager is in touch with us via emails, checking in about various matters, reviews, complaints, or anything else, which is great.

I previously used Flagsmith for our flags and feature flagging but switched to LaunchDarkly due to its superior features, including variations, flexibility, rules, targeting, and other options that were lacking in Flagsmith.

I advise others looking into using LaunchDarkly to go through the documentation thoroughly and select their use case since there are a lot of options available, but you do not need to go through each and every one. Just identify what relates to your use case because if you explore everything, it might become confusing, and you could struggle to switch to or effectively use LaunchDarkly. Focusing on your specific use case will help you find your solution in LaunchDarkly, and you might not have to use all of its features at once; you can use a part of it initially and later integrate additional features.

LaunchDarkly is working great, and I would encourage them to continue their excellent performance. They should aim to simplify things and avoid adding complex features that could complicate the product overall; keeping it simple and focused on use cases will keep it good. I am providing a review rating of nine for LaunchDarkly.

Private Cloud

Amazon Web Services (AWS)

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)