LaunchDarkly

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.

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.