LaunchDarkly Reviews

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)

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.

LaunchDarkly offers several outstanding features. There's the main functionality of LaunchDarkly, which is providing feature toggle functionality. They also provide a relay proxy, which allows us to increase performance, as well as provide functionality for our feature toggles in the event that connections to LaunchDarkly go down. Some of the more impressive and useful functionality are the targeted feature toggling, as well as different segments that allow very specific targeting of users and context, with the ability to get very granular and complex with feature toggling rules. Additional functionalities include the ability to see how feature toggles are being utilized, how often they're being evaluated, as well as a scanner that helps users determine which flags can be retired and which flags still need to be used.

These features in my current project have helped my team because they allow us to specifically target users to start turning on functionality. We can monitor the behavior and make sure that it's behaving as expected when the feature toggle is turned on, and then we can increase the usage. In previous projects, we've also used the targeting and the segments in a similar fashion, and we could target it towards both internal and external customers based on the context being passed to LaunchDarkly as it's evaluating the flags.

I wish we were using more targeting in our feature toggles and I wish we were using more feature toggles as well as feature toggle dependencies. Making one feature toggle or one set of feature toggles dependent on another one would allow us to turn them all on or turn them all off at one time.

For improvements in LaunchDarkly, managing team members and access to those team members was challenging. We could add team members through Terraform and do it programmatically, and then modify it through the user interface. However, once we started modifying things through the interface, we weren't able to go back to using any configuration programmatically for the team members. It made it challenging to orchestrate team member management. The other aspect I wasn't particularly fond of was when they started adding AI to the interface and deployment interface. It reminded me of old school wizards when installing software and simplified the interface too much, removing some of the engineering control I preferred.

I have been using LaunchDarkly for about the last three or four years.

LaunchDarkly is incredibly stable in my experience.

I can't say for certain about LaunchDarkly's scalability with my current organization. However, in my previous organization, it handled scaling excellently.

I have not interacted with the customer support team at my current organization. However, at my previous organization, I interacted with them quite frequently, and they were absolutely great. They were stellar, super polite, super fast, and usually really knowledgeable.

I would rate the customer support a nine because there were a couple of times where we got handed off to junior support techs who didn't fully understand what I was asking.

Positive

I did not use a previous solution at either of these organizations. At my previous organization, there was a homegrown solution and by the time I left that organization, we were in the process of transitioning them from the homegrown solution to LaunchDarkly. The reason they wanted to get off of the homegrown solution was because it had become too large and too complex and too difficult to maintain.

For my current organization, I can't say one way or the other about return on investment. I've never had a challenge getting access except for team member configuration. At my previous organization, we were having issues due to licensing costs and agreements. We were eventually able to get it to a point where a very small team could administer access to LaunchDarkly for thousands of employees. The pain point of configuring the basic configuration using Terraform came into play, allowing us to hand off the management of LaunchDarkly teams to the development teams so they could handle permissions as long as we set out a set of permissions they could choose from. That made things easier. However, that's where we started experiencing the pain point of once things started getting modified through the dashboard, we couldn't get them back via Terraform.

At my current organization, I have no experience with licensing and setup cost. However, at my previous organization, I wasn't making any decisions but got some visibility into the pricing and usage. That organization was incredibly large, and we had an incredibly high usage rate, so we were getting some custom pricing.

Before choosing LaunchDarkly at my current organizations, I was not involved in those processes. For some of the smaller organizations and startups I've been working with, we have been looking at other possible solutions. Unleashed is one of them, and I think that's the one I'm leaning towards. I'm not particularly enthusiastic about their functionalities. However, they tend to come at the right price point that I need.

If you can afford it, go for LaunchDarkly. It's a great tool. I really enjoy using it. I wish there was a lower tier for startups and small companies. On a scale of 1-10, I rate LaunchDarkly an 8.

Public Cloud

Amazon Web Services (AWS)

Regarding my use cases for LaunchDarkly, I have tried to find more creative ways to use it, but it boils down to feature flagging features. I've attempted ways to implement more complex uses, but the business is resistant to doing much more than that. I want to do release gates and configurations. I've used it for gating a service. I had a GitHub action that would run on multiple workflows, and sometimes I needed to do maintenance. I set it up so that if I set the flag, it would enter maintenance mode and wouldn't run any other workflow actions, but it wouldn't fail, which is what I didn't want. This worked very well. I ended up getting rid of that service and everything, but other teams found this GitHub action using LaunchDarkly flags and found it useful. They have been using it for other things. This happens a lot with GitHub actions, since it's sometimes hard to go into everybody and tell them about maintenance. It's very easy to just use a feature flag where you can not fail them because then you'll get a lot of messages about it. Instead, you can tell them softly that the action didn't run because this is in maintenance mode. If they really need it, they can just wait. I set it up so I could also put a message saying we'll be back in two days or two hours, whatever. Essentially, it is mostly feature flags.

I love the stats and seeing how many times a flag got hit. All of that is handy. The feature flagging part is excellent, very fast, and very nice and intuitive.

When asked if there's anything LaunchDarkly can do better for me, I wish I could use it more and could give a more in-depth response. My main concern is that when I was trying the GitHub action functionality, what I was trying to use it for should have been something native and supported. I found that there were a lot of similar implementations done by DataDog, and it was confusing because I didn't know which one to use or fork off. I would say clean up some of the dev tooling in GitHub, especially for the GitHub action functionality. Maybe have a few that are very clear on what they do. Being able to run a GitHub action to check a feature flag is very handy. The last time I checked, it's not an explicitly supported thing, and I had to build the functionality myself. I understand LaunchDarkly is more focused on releases and live production functionality, but if they can also expand into dev tooling, I think that would be great.

A feature flag should be very simple, should be true or false with a little description. If you want to do more fancy things with it, then you should be able to do an expanded view. Most of your main client base are developers and most of them can figure things out, but you'll be surprised at how many can't. The basic true or false Boolean feature flag UI should be very simple and very clear. Sometimes it feels like there's a lot going on and I just want a Boolean feature flag. If it's false, I want to switch to true. If it's true, I want to switch to false. Beyond that, I love the stats and seeing how many times it got hit, all of which is handy. When I'm setting a new flag, I remember the first time thinking this is way too much going on here. The basic functionality should be very simple, and if you want to get fancy, then show more options, but not from the start.

Professionally, I have only used LaunchDarkly. For my personal projects, I have used PostHog. They make it slightly more simple, at least on the feature flag part. Maybe it's just the nature of the tool and it's a UX problem, or maybe it's because you have a bunch of developers creating things for developers so we don't care that much about the UX. It's just too much. You should be able to have a simple true or false option.

I would say you are a little over-engineered, which makes it harder for developers. I've seen developers struggle, get annoyed by it, and just not use it as much. We kind of have to get to the point where we force them, telling them that every feature they release has to have a LaunchDarkly flag. Whereas it would be nicer if they would see the value right away and just create flags.

In relation to how long I've been using LaunchDarkly overall in my career, I would say about four years.

Regarding stability of LaunchDarkly, I have no complaints. It's fast and works well.

On the topic of scalability, we have used it across many applications in many different ways. Some of the front-end teams are using the client side instead of the server side. I've never heard any complaints about how scalable it is or how quick it is. If you understand how it works, you can set it up in a way that is not problematic. You can cache a lot of the responses and even create tests. LaunchDarkly offers handy documentation on how to set up testing for it.

A feature flag should be very simple, true or false with a little description. If you want to do more fancy things with it, then you should be able to expand. I understand most of the main client base are developers and most of them can figure things out, but you'll be surprised. The basic true or false Boolean feature flag UI should be very simple and very clear. Sometimes it feels like there's a lot going on and I just want a Boolean feature flag. If it's false, I want to switch to true. If it's true, I want to switch to false. Beyond that, I love the stats and seeing how many times it got hit. When I'm setting a new flag, I remember the first time thinking this is way too much going on here. The basic functionality should be very simple, and if you want to get fancy, then show more options, but not from the start.

When considering alternatives I've used compared to LaunchDarkly, we had a homemade solution before for feature flagging. It wasn't great and was a very custom thing. As far as an actual competitor, I don't think so. We had a homegrown product that worked okay, but it would break and was not very friendly to use. Documentation was poor. It was just a homegrown product. It was not a great experience. When we switched to LaunchDarkly, being a manager on my side of the organization, we did a lot of work trying to push it because we liked it so much. Now things are better and I think it has been adopted widely. As far as all the teams that I worked with, a lot of them use it.

Concerning the initial deployment of LaunchDarkly, maybe because I wasn't too familiar with tools of that type, it was a little hard to get started. Once you got the hang of it and once it clicked what it's trying to do, it was pretty easy. It does feel like drinking from a fire hose sometimes with LaunchDarkly. I feel developers should be introduced to the feature flagging part first, which I feel most of them understand. I think you do a very good job at it, very fast, very nice, and very intuitive. Then start introducing the other functionality, because it does feel like you do a lot and it wasn't very clear. There were points where I was wondering if LaunchDarkly even does feature flagging the way I wanted to do it. A lot of developers get confused too. I've had to onboard a lot of developers to LaunchDarkly because being one of the early adopters in the company, at least on my side of the organization, my name got attached to it. A lot of people would come to me after seeing that I had worked on it before. I onboarded several teams, was an owner for some of the groups. They would come to me a lot, and once I got on a call with them, I would say, I know there's a lot going on here, but the one that you care about is the feature flagging. Then go through the docs and learn more about it. There are other things that you can do, but the main thing that most people reaching out to me needed was because their managers told them they needed to start using LaunchDarkly. They didn't have any idea how to start.

Maybe there should be a more centralized way of implementing this and having centralized documentation on how to use the tool. It doesn't really change that much from team to team. Everybody kind of uses it the same way. Maybe there should be some kind of centralized effort to have centralized documentation that can help you get started. Here's how you request access to it, here's how you create flags. The whole way that the ownership is set up and who can allow access and the way the teams are named is very confusing. I felt we had a good thing and now it's kind of confusing and it has taken me a while to figure out what group I belong to and how I add people and how to get them access. LaunchDarkly in particular seems a little more difficult than the other tools that we use. Maybe the LDAP integration is not the greatest. Whoever implemented this in the company may have just done it poorly, but whoever implemented it should go through how they implemented it and maybe there's a better way to do it. This is very confusing right now with who gives access and who's the owner. That's why people still come to me years after I stopped being a daily user of it.

I understand that LaunchDarkly may not have a solution for everything. We're trying to implement LaunchDarkly in some ECS instances to do feature flagging in ECS. The last time I checked, there wasn't a clear way of doing it. I managed to find a way though. There's always enough documentation. LaunchDarkly deserves credit for having good developer documentation. You cover a lot of cases and there are multiple ways to enable it. There are enough ways to make LaunchDarkly work in the multiple types of environments that I've had to make it work, and I've always found a way. It's not super hard. Whoever's implementing it depends on whether they know how to dig through developer documentation. LaunchDarkly provides enough information.

On a scale from one to ten, I would rate LaunchDarkly as a nine overall. Now that I have used PostHog and I'm pretty sure their main focus is not feature flagging, but they do have it and it's pretty nice that it's part of their suite. You are a nine. You do almost everything that I need from you well. If I knew more about the pricing, I would give you a value ranking, but as far as a functionality ranking, you are a nine. You do almost everything pretty well and pretty fast. The UX is a little confusing. There are a lot of parts that feel over-engineered. I have learned that now that I have my side projects with users and they complain to me that things are not very simple looking. My main concern would be that you are a little over-engineered. It does make it a little harder for developers. I've seen developers struggle, get annoyed by it, and just not use it as much. We kind of have to force them, telling them that every feature they release has to have a LaunchDarkly flag. Whereas it would be nicer if they would see the value right away and just create flags without being forced. My overall rating for LaunchDarkly is a nine out of ten.

My use cases for LaunchDarkly involve managing risk from new features such as AB testing and canary releases for features with gradual rollouts. This type of work is fundamentally about managing risk and testing new features.

I haven't used LaunchDarkly to manage any AI in production; the only thing I've used it for is feature flags for the most part.

What stands out to me about LaunchDarkly is that it's super easy to use. I appreciate that you can serve the feature at a percentage and that you can add users by email. For example, I used it in the past to do internal-only testing of the feature in production, which was very helpful.

From what I've seen, the management of feature flags in LaunchDarkly is pretty good. I don't have any other reference point to compare it to, but it's pretty simple to create a new flag and then edit the flag and increase or decrease traffic to that flag. I'm not an expert on feature testing, but for what I've used, it works for what I needed.

If LaunchDarkly goes down and you don't have it set up right, it could be a problem for you. I think that's a little bit on user error as well.

I would like some sort of a local instance to be available.

I've been working with LaunchDarkly overall for at least a few years, probably around three years.

I've seen lagging, crashing, or downtime with LaunchDarkly. There was an outage, and that's what I was referring to. If there's ever an outage, I think you can define a default experience in your code, but I don't think we did that well. It might have reverted to an experience that we did not want the customers to see. For instance, my company developed a new version of our checkout page, and it was behind a LaunchDarkly flag, but it was serving 100% traffic to that flag. But when LaunchDarkly went down, it started using the prior checkout page, which is not as good of a page, which is why I'm saying that it's a problem if LaunchDarkly goes down.

Regarding scalability, I think LaunchDarkly is pretty scalable. I've never had issues with it scaling.

I've never actually used anything similar to LaunchDarkly, but I'm aware that there are competitors; however, LaunchDarkly is the only one that I've used.

The initial deployment of LaunchDarkly was handled by a platform team that managed that initial setup, but as far as integrating it to my service, it's pretty easy to just create a LaunchDarkly client, much like any other type of client for any external software that you use, and then just go ahead and start using the flags.

LaunchDarkly usually does not require any maintenance on my end. It's usually taken care of. The only time we have maintenance is if we're not using any flag anymore, or we make it a permanent feature instead of a feature flag; then we'd have to go into the code and clean it up to delete the flags and then delete it from LaunchDarkly. But in terms of maintenance outside of that, there isn't much required.

On a scale from 1 to 10, I would give LaunchDarkly an 8. I would definitely recommend it to another customer. It's always worked for me, except there have been outages here and there, but very rarely. I'd say it's pretty good for the most part.

My use case for LaunchDarkly is for releasing features that we don't want to make available to customers immediately, or for beta testing. We put features behind feature flags and perform continuous deployment. Every week we deploy to production, but the whole feature is not available for clients, so we put it behind LaunchDarkly feature flags.

I have not used LaunchDarkly to manage AI in production, models, prompts, or agents.

What I like most about LaunchDarkly is the ability to create segments easily. You don't have to create rules repeatedly. You just add your specific requirements into the segment and proceed from there without reworking the entire flag or rules.

Over the period, I have seen measurable improvements in metrics such as evaluation scores when I implemented LaunchDarkly. They have made improvements, especially in enabling it globally and enabling it for a particular client, which makes a difference. Turning it off and turning it on was not a feature previously, but now it is much easier. If nothing is working, you can simply turn it off.

In the new UI where they have put production and related items next to each other, I find it is sometimes hard to determine if a feature flag is on in production or off. Looking for that specific information in the new UI was not pleasant for me.

I have been working with LaunchDarkly for almost five or six years.

Regarding stability, it happened in four or five years of usage a couple of times that it was not syncing properly. Over the period, it got better.

I would rate LaunchDarkly a seven in terms of scalability.

I have not used anything similar to LaunchDarkly. We have been using this product for a long time.

The initial setup was easy, and I was able to train my team. It took a couple of weeks and a couple of deployments for everyone to fully understand how to set it up for our company.

I have been working in my current field overall for 15 or 16 years. The maintenance is taken care of by the team. I have not integrated any other tools with LaunchDarkly. I would give LaunchDarkly an overall rating of eight.

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)

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.

I find LaunchDarkly very easy to use, with flags that work really well; it is very convenient and fast to toggle features on and off, and its integrations with different platforms and libraries are really good, making it overall perfect.

LaunchDarkly has positively impacted our organization by allowing us to confidently ship products across different environments, knowing we can easily turn off any feature that faces issues.

LaunchDarkly stands out due to its ease of use, deployability across environments, and the ability to easily toggle features, which are all beneficial qualities.

I did not particularly like the rule area; there are many things to add into the rule to enable it, and I think we could make it easier or more customizable at the organizational level.

If the rules could be a bit more user-friendly, it would be helpful.

I have been using LaunchDarkly for five to six months.

LaunchDarkly is stable.

SailPoint uses LaunchDarkly across a lot of employees, and we do not face many problems regarding scalability, so I think it is good and scalable.

I have not reached out to customer support for any reason, so I am not much aware of it.

Prior to LaunchDarkly, we used to organize our code via a Git branching strategy, which had its limitations and risks, making it not environment-friendly or customizable, issues that LaunchDarkly has helped solve.

I mentioned earlier how we previously used Git branching for multiple feature rollouts, which was complex and not very environment-friendly, making LaunchDarkly a better solution.

I cannot speak on money saved, but time saved is evident because we can ship products faster with more confidence, although I do not have metrics to quantify it.

Public Cloud

Amazon Web Services (AWS)

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.

The best features LaunchDarkly offers include feature flags itself.

Feature flags are valuable for my team because of delivery speed.

LaunchDarkly has positively impacted my organization as the value we deliver to customers is much faster, and we saved a lot by using this feature instead of implementing it ourselves.

I think LaunchDarkly's customer support can be improved as it is not responsive. I do not have anything else specific to add about needed improvements besides customer support.

I have been using LaunchDarkly for more than three years.

LaunchDarkly is absolutely stable.

The scalability of LaunchDarkly is perfect.

Regarding customer support, I once scheduled a call with customer support, the link was not working, and customer support did not get back to me.

Before LaunchDarkly, there was no solution implemented.

I have seen a return on investment as employees were saved time.

My experience with pricing, setup cost, and licensing is that pricing is great, affordable, and fair.

I evaluated other options before choosing LaunchDarkly, including some services provided by Amazon, but I decided to proceed with LaunchDarkly.

My advice to others looking into using LaunchDarkly is to discover all the feature advantages provided by LaunchDarkly. I gave this product a rating of 9 out of 10.

Private Cloud

Amazon Web Services (AWS)

My main use case for LaunchDarkly is that my company uses it for feature flags and experimentation, and for my team specifically, I work in the platform team, managing the infrastructure to support LaunchDarkly.

A quick, specific example of how my team uses LaunchDarkly for feature flags or experimentation is a basic use case where we have an API and a feature flag to turn on new features, and for experimentation, we test out the features to a subset of customers before releasing it to everyone.

The best feature LaunchDarkly offers is the capability of having a feature flag that we don't have to build in-house.

LaunchDarkly has impacted our organization positively by giving us a feature flag and experimentation capability, which we didn't have beforehand.

It seems to be quite expensive for what you get, and for my team specifically, where we manage the infrastructure for LaunchDarkly, it seems overcomplicated and very hard to maintain as we have to deploy a custom component that we host internally, which seems odd for a SaaS product.

To be honest, I don't think there's much time saved overall for Seek based on the overhead of having to maintain the infrastructure internally regarding the value of having this capability without building it in-house.

The documentation online on how to use LaunchDarkly in your SDKs is not great; it's too broad and not specific enough.

LaunchDarkly could be improved by making it cheaper and also reducing the overhead of having to maintain our own infrastructure internally because that really completely defeats the purpose of using a SaaS provider. When you look at the overall seat costs, the engineer time required to manage this infrastructure internally is nontrivial and already I believe it exceeds the benefit in terms of license cost; we may as well have just built our own.

For the documentation, it would be very good to have clear examples of which pattern of LaunchDarkly to use in what use case; for example, when to use the feature store only, when to use the feature store with the persistent store, and when to use the big segments, as it causes a lot of confusion for our internal users. When I say users, I mean our developers using the SDKs, and it's very difficult to point them to which pattern to use. Each of these patterns means a different type of infrastructure that we need to maintain with the relay proxy, which is all very complicated for such a simple use case.

I have been using LaunchDarkly for about two years.

LaunchDarkly is probably stable, but it's unclear in terms of the stability of the infrastructure that we have to run internally; there are a lot of moving parts that we have to ensure are stable, otherwise LaunchDarkly becomes unusable. While using a SaaS provider, we still have to do all the heavy lifting in-house to put in the monitoring, the SRE, and alerting, which seems overkill for using a SaaS.

The scalability of LaunchDarkly is not great because we have to scale internally with the infrastructure that we deploy.

The customer support is average compared to other vendors; it's not as responsive as I would expect.

Previously, we used an in-house built solution, and the idea was our teams that wanted to use the features of LaunchDarkly around experimentation didn't want to build their own.

We did not purchase LaunchDarkly through the AWS Marketplace; it was through direct negotiations with the vendor.

I don't see any return on investment; I work in the platform team that has to manage the LaunchDarkly infrastructure, and I can't really see any return on investment. We've burnt at least four quarters of effort to get it running and running effectively.

My experience with pricing, setup cost, and licensing is that I wasn't directly involved in pricing, so I have no visibility on that, but I do know from what I've been told that it is very expensive.

My advice to others looking into using LaunchDarkly is to carefully assess not just the features like using it as a SaaS, but also the tax that you have to pay by having to run your own internal infrastructure, i.e., the relay proxy, to actually get it working effectively. That is nontrivial, and for a SaaS, I expect this to be all out of the box and not something we have to deploy internally.

If I had to go back in time, I would not choose this product. My review rating for this product is five.

Private Cloud

Amazon Web Services (AWS)

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.

The best feature LaunchDarkly offers is the flag that allows rollouts.

What I appreciate about LaunchDarkly is that the setup was easy, it had a clean user experience, and the control allowed us to manage the features without deploying them to everyone. We could deploy it gradually and then roll out easily. I particularly value the ability to click to turn the feature on and off.

LaunchDarkly has positively impacted my organization by reducing the risk of releasing new features because we did not have to expose everything to all users at the same time. It eventually resulted in faster releases and more confidence. It also saved engineering time because in some cases, we did not need to do a rollback or hot fixes; we could simply disable the feature flag. Additionally, it reduced the QA time since they could only test a specific area.

LaunchDarkly can be improved by managing old flags. We have an issue with old flags; it became very messy very fast and we need to be very disciplined about managing these flags. I also heard from the manager that it was very expensive when the usage grew.

Perhaps LaunchDarkly could mark old flags somehow or add a tag to these flags when they are not in use or have not been used for a long time. We found ourselves after a short period of time having too many flags.

I have been working in my current field for above ten years.

I used LaunchDarkly in my previous company for several months.

Overall, LaunchDarkly saved our engineering time and helped us manage features very smoothly, allowing us to gradually deploy and roll out.

My advice for others looking into using LaunchDarkly is to manage the flags carefully, as it can become messy very fast.

I believe LaunchDarkly is a very useful tool for teams wanting to release features quickly and safely; it gives a lot of control and helps reduce the risk around production releases. I would rate this product an eight out of ten.

Public Cloud

Amazon Web Services (AWS)