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.