LaunchDarkly Reviews

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.

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.

I have been working for the client Windstream, which is an enterprise platform where we develop an Appysuit application. We are testing new features without releasing them to all customers, instead releasing to selected customers. I use LaunchDarkly for feature enabling and disabling.

The main feature I value is the user-friendliness, especially the flag enabling and disabling. The API integration is also impressive. I appreciate the UI which allows easy enabling and disabling of flags.

I have used LaunchDarkly for around two and a half years and I haven't faced any issues with it.

I have been using it for two and a half years.

Performance-wise, it's very good. It has never gone down in the two and a half years of use. The server has been very stable.

LaunchDarkly is very good for scalability and makes scaling up easy.

I did not use any previous solution.

The setup is easy. It is just a click and it provides three environments for development, UAT, and production. It's easy to manage all environments.

Pricing is all handled by my project manager; I don't have any costing information.

I did not look into any alternatives.

I would suggest using LaunchDarkly if the application is complex and you have to test many features for future purposes, particularly for enterprise applications. For small applications, I would not suggest using LaunchDarkly. It's easy to use, easy to integrate, and user-friendly.

I'd rate the solution eight out of ten.

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.

The application is highly intuitive. The UI offers robust controls, allowing you to set rules, schedule releases, and establish dependencies. For instance, if a particular flag depends on other flags or features that need to be deployed first, you can also configure that. The application provides a deep level of configuration options.

When the system has an excessive number of feature flags, managing them can become cumbersome. It would be helpful to have UI elements that make this easier, such as tracking feature flag usage, the duration that feature flags have been open, and generating reports.
You need some experience to get used to it. There's a bit of a learning curve, but it is easier for people with a technical background,

I have been using LaunchDarkly for one and a half years.

We experienced one brief outage with the system, which almost did not impact us. LaunchDarkly maintains a local copy of your rules, so our system usually functions. However, our ability to set up new feature flags was limited. 

I rate the solution’s stability a nine out of ten.

It's designed for scale. We didn't have a considerably large footprint, with most use cases involving single users at a time. They have a large user base of about a hundred million customers, but these customers typically visit once or twice. However, LaunchDarkly is used by companies with significantly larger footprints, proving it is designed for scale.

Support was game-changing for the organization in terms of its ability to release things with a significant risk reduction. It has pretty comprehensive documentation.

The initial setup is very easy.

It allowed us to deploy faster. Despite having a rigorous code review process that slowed things down, once the code was reviewed, LaunchDarkly enabled safe deployments. If there was ever an issue, we could easily roll back a particular release by simply turning off the feature flag.

When configuring and setting this up, begin with feature sets that are relatively small in scope. This helps build the necessary skills to leverage the product effectively while maintaining control over the blast radius, thus reducing risk to your customers and application in case of misconfiguration. As you gain more experience with the solution, it's crucial to have a process to manage feature flag sprawl, as mentioned earlier. Implementing a life cycle management system for your feature flags is essential.

Overall, I rate the solution a nine out of ten because of its intuitiveness and ease of use.

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.

Targeting rules have improved our deployment process. 

Our deployment process has become much faster. We are able to keep rolling out to production even if a feature isn't fully ready. We simply don't enable it until it's complete. LaunchDarkly also helps with certain business use cases that require time-sensitive run-time decisions.

For instance, during validation processes, both conditions need to be met, but the upstream system isn't ready. We can still provide support and, in the future, transition smoothly.

Imagine a scenario where you need to accept both five-digit and ten-digit order numbers, but your system isn't ready for ten-digit numbers yet. LaunchDarkly allows you to support both initially and then, when all other services are ready, enable the ten-digit feature. This makes the rollout seamless.

It has really helped during the series of product lines and faster deployment and faster development. 

LaunchDarkly currently lacks multi-region support. I strongly believe they need to develop a strategy for handling situations where LaunchDarkly goes down. They should have a backup URL and collaborate with other engineers to ensure availability. There should be a fail-over strategy in place. My understanding is that a multi-region real-time solution isn't available yet.

Another future enhancement I envision is having the entire application property load through LaunchDarkly. This integration would be advantageous but needs to be designed to be very user-friendly and serviceable.

I use a dashboard. I see some improvements happening, but it's a little bit cluttered. It even needs to be improved because certain kinds of levels of fields are added. So they need to make it very user-friendly, that kind of thing. So, LaunchDarkly really has to play around and make it very user-friendly.

I expect certain behavior from the tool, but it gives me false results. I know I need to play around with all the properties, and then I can go to what it takes.

It's not a tool that a non-technical person can use. Like, whoever is a non-technical person can also easily able to understand what they want to do; that kind of thing used to be taken as part of the dashboard (cloud dashboard), which is wherever we are enabled with your feature, like, so because If you go inside the plans, it has, like, a certain level of conditions and operations. So sometimes it works well, sometimes it doesn't work. So everyone has to understand. So, that needs to be very precise.

We started using LaunchDarkly about two years ago for a major project related to commerce and transactions in the retail domain.

We had a few issues. They have a default property system, but I don't know. Somewhere, I realize that even LaunchDarkly takes a little bit of time latency-wise.

There is somewhere an area that requires improvement because this is considered every time I go, I know it has a streaming process. It does not do it every time, but wherever it does, I realize, like, whenever I am checking with my APM tool, I can see it makes a network call every time, which shouldn't take more than five seconds. That mechanism is required. So one time, like, whenever our application loads, your vendors should come and, like, whenever we do some level of changes, that will be notified to our services and update those vendors.

Because that is, like, I should not have to check alerts every time at the API call whether a flag is false or true. So, wherever we do certain actions. But because this flag is not gonna be frequently updated. So that is gonna be the business condition. It could stay around for one month, one year, or two years in our group. 

So when this comes, it should be like large lags should notify our services. So maybe their SDK should reflect this only one time. Then, we should not make any call to our server.

I don't think it's yet scalable. Because multidimensional and multi-use features are required. For scalability, everything needs to be updated. I don't think it's heavily used because we probably consider; what if we have billions of requests? So, the system should always be scalable. It should be automated and scalable. It should start using Kubernetes, which takes care of scaling in and out based on the load.

The initial setup is just an SSO. You already have an SSO. I don't know whether the SSO is available, but if it is not, it needs to be introduced at the company level. The company needs to be SSO-logged.

So they don't want to collaborate and create an account and everything. Ideally, this should be logged in through the SSO. That should happen with our server only. That is one thing I believe. It was not there six months before, but I am not currently aware.

So if it is not, that should be introduced. The login should be there so they can manage product sales and non-product sales.

Set alone, we can't control as an organization. We can't provide access to everyone.

We have a license. From what I heard from my other team members, the licensing cost is a little high. So it needs to be cheaper. 

If it's cheaper, any organization will involve more users.

Overall, I would rate it a seven out of ten because it has a lot of improvements yet required.

I would recommend it until, like, there are a lot of things available in the market. It's company to company how they want to implement it.

LaunchDarkly is a great tool. But consider whatever service you need to make sure your system is scalable, multi-region, multi-area. Those things are very important whenever a company tries to onboard any new external services.

LaunchDarkly is used for feature flag implementation. It allows me to control product release by deciding whether to show certain features to users. I can also control feature visibility remotely by toggling flag values.

LaunchDarkly helps avoid complete rollbacks when multiple features are released, and one causes an issue. We can simply turn off the problematic feature, saving on redeployment and testing cycles.

I appreciate that we can release any feature in production and maintain control over it. If something goes wrong, we can go to the portal, turn off the flag, and manage the situation remotely.

Fetching information about multiple flags in a single action would be beneficial. Additionally, incorporating some analytics on LaunchDarkly would enhance its functionality.

I have been using LaunchDarkly for more than one year.

I have noticed stability issues in terms of backend performance, such as delays.

LaunchDarkly is scalable; however, there are areas they could improve on to enhance scalability further.

I haven't yet needed to use customer service, however, support is available for raising questions or queries if necessary.

Positive

Before using LaunchDarkly, we had custom services with config tables for feature control. These were difficult to maintain, and there were higher risks of causing issues in production. LaunchDarkly provides a more user-friendly interface and control.

The initial setup process was straightforward, assisted by good documentation provided on their site.

The ability to avoid rollbacks saves a significant amount of time during deployments, leading to a more efficient development process.

LaunchDarkly is a licensed version and not free. I am not aware of the specific costs or billing details.

We considered using Firebase. Ultimately we did not implement it.

You can achieve smooth releases with LaunchDarkly while maintaining control over them. It helps avoid compliance issues by allowing feature adjustment at any time.

I'd rate the solution nine out of ten.

Our developers are using LaunchDarkly. I am using it to turn on features.

Recently, I like this new update where we can see and manage everything through it. Also, from the development side, it allows us to manage multiple things. Additionally, I like the services provided, like managing through the internet on and off.

As of now, I do not see much room for improvement. The feature where one feature flag is dependent on another could be explored more for our usage.

I have used it for almost two years.

Sometimes it breaks down. Only last week, we were getting a 500 error.

Users can easily scale up or down.

I have not contacted their support team for any reason.

Positive

The initial setup is easy.

I am not sure about the pricing or setup costs. It is all handled by our organization.

You can manage through the reach of flags for different credential regions. You can turn on or off features for different environments. This is pretty useful.

I'd rate the solution nine out of ten.

We use LaunchDarkly for managing feature flags. It helps manage the keys to control what users view on our screens.

By managing the feature flags, we can target users and control what needs to be visible on their screens.

I like that it offers the ability to control the flags.

We need experience to use it, and the initial setup can be difficult. Also, sometimes it has breakdowns.

I would rate LaunchDarkly a seven out of ten.

I have been using it for almost two years.

Sometimes it has breakdowns.

It is easily scalable.

The initial setup is a bit difficult.

I consider the pricing to be high.

I would recommend new users to use LaunchDarkly because of its advantages.

I have been using LaunchDarkly for more than one year due to the nature of my projects. Whenever we want to avoid multiple builds, we use a flag to enable future changes in the production environment.

LaunchDarkly allows us to control deployments without multiple builds. It enables us to show the status of tasks to clients when necessary, and when a task is not complete, we can prevent it from being visible by turning off the flag.

The ability to turn off a flag is crucial when a task is not complete, especially if there is an error in a commit. This feature ensures that uncompleted tasks are not shown to clients.

Right now, no improvements are needed. In the future, after further analysis, if I have any concerns, I may change my mind.

I have been using LaunchDarkly for more than one year.

I have not faced any issues with the stability of LaunchDarkly.

I just used it for one feature. I need to analyze fully in LaunchDarkly and review the documentation. If I have any concerns, I will let you know.

I don't have an idea about the support team as I didn't have to contact them or open a ticket.

Neutral

The initial setup was straightforward and not complex.

I do not know the cost of LaunchDarkly as it was implemented offshore. I am not aware of its pricing or whether it is a free or paid source.

I would recommend LaunchDarkly for projects with multiple builds. If you wrongly commit tasks, turning off the flag ensures features do not show up for the client.

I'd rate the solution seven out of ten.