Feature flags certainly aren't new -- anyone who has been into SaaS and staged rollouts of production changes likely has built their own or leveraged libraries that implement feature flags. However, the downside of homegrown or library-based models soon becomes visible once you have a more focused organization where each group focuses on what it does best (product vs engineering vs customer success). As Joel Spolsky asserts in defense of NIH syndrome (https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-...), do build what is critical to your business. For a business that revolves around user modeling/behavior/marketing, it would make some sense to build your own. For example, Mixpanel or Totango could probably use their own internal segmentation engines to target users for new features, thereby 'eating their own dogfood'. I work at Upserve, where we provide software to help restaurants and bars run their businesses better. We are obviously not directly in the business of producing feature flags for our customers, but we leverage the hell out of them.
Here are a few key benefits I've seen as an avid user of LaunchDarkly, that are end up costing a lot to build on your own:
- ability to have people outside of engineering control who gets access to what features. Specifically, product management should have control over what features are available, and they probably don't want to go into a dev console to make the changes. Sure, you could build a UI on top of home grown FFs, but why spend valuable time on this?
- rules-based user targeting -- rather than embedding ugly logic into your code about what type of user should be served a feature, you can handle most of that within LaunchDarkly's UI. For example, we have some restaurant groups that have 100's of locations. Rather than setting values at the ___location or <gasp> user-level, I can simply set a flag at the restaurant group level and that automatically propagates to the user level. Sure, you could build this hierarchy into your homegrown tool, but I guarantee doing that in a very flexible manner won't be a slam dunk, and you'll soon find that you will want to change it and have to invest more time on something that may not be core to your business.
- custom rollout -- you can roll out by % of users or user properties. For instance I can roll out to 10% of users that are in Rhode Island, US. Did you really add this to your homegrown FF service? I hope you didn't tell your VCs that if so...
- centralized feature flag service -- we leverage across dozens of components, and use feature flags centrally on our cloud servers and on 1000's of agents installed inside our customers' locations (and on hardware that we don't own). Since LaunchDarkly uses server-sent events (SSE) this introduces no additional latency in making network calls to a central server. Changes to users and flags are sent streaming, seamlessly, behind the scenes, with minimal network impact. This key infrastructure decision that the team at LaunchDarkly made has given us confidence of using feature flags wherever we could feasibly imagine them without having any adverse impact to us or our customers. Oh, did you remember to build that into your homegrown FF solution?
- multivariate flags -- LaunchDarkly supports multivariate flags. For example, we throttle data transport for some of our remote agents. We can control this centrally so that certain agents only send back certain amounts of data (e.g. 1MB, 5MB, 10MB per batch of data sent). This actually extends the concept of FeatureFlags -- there are discrete variations within a single 'flag'. Don't forget to build that into your homegrown solution too.
- feature flag chaining -- you can specify a prerequisite for a feature flag. For example, for a rebranding of an entire website, you could have individual feature flags for each page, and then have a 'big bang' flag that does the entire thing at once. This allows you to test and manage 'micro features' but then turn on the 'major feature' easily.
- they have thought a lot about the technical debt that feature flags can introduce. How often have you added a feature flag only to not use it again or forget to remove it? It can make your code base ugly in a hurry. LaunchDarkly has analytics that help you identify usage paths as well as 'flag the flag' so you can be more conscious about what is a temporary vs permanent flag. This might not sound like much, but it prevents questions later about 'can we remove this flag' without causing impact. You've future proofed your homegrown solution to grow into this too, no doubt.
- organizational visibility and integrations with third party services -- LaunchDarkly has many integrations already built into it. For example, we use it to post to our #product channel in slack, so we can see when a new feature becomes available and when someone changes an existing flag/adds users to it. This has made communication about features much less time intensive because anyone can see the current state of a feature. You didn't really build a Slack integration or create a bot just for your homegrown feature flag service, did you?
If you think you'll eventually be in the place where what I've spoken about would be helpful, I would strongly suggest you consider a service like LaunchDarkly early in your development so that you can focus your energy on the right things and take advantage of the hard work that LD is putting into their service.
Here are a few key benefits I've seen as an avid user of LaunchDarkly, that are end up costing a lot to build on your own:
- ability to have people outside of engineering control who gets access to what features. Specifically, product management should have control over what features are available, and they probably don't want to go into a dev console to make the changes. Sure, you could build a UI on top of home grown FFs, but why spend valuable time on this?
- rules-based user targeting -- rather than embedding ugly logic into your code about what type of user should be served a feature, you can handle most of that within LaunchDarkly's UI. For example, we have some restaurant groups that have 100's of locations. Rather than setting values at the ___location or <gasp> user-level, I can simply set a flag at the restaurant group level and that automatically propagates to the user level. Sure, you could build this hierarchy into your homegrown tool, but I guarantee doing that in a very flexible manner won't be a slam dunk, and you'll soon find that you will want to change it and have to invest more time on something that may not be core to your business.
- custom rollout -- you can roll out by % of users or user properties. For instance I can roll out to 10% of users that are in Rhode Island, US. Did you really add this to your homegrown FF service? I hope you didn't tell your VCs that if so...
- centralized feature flag service -- we leverage across dozens of components, and use feature flags centrally on our cloud servers and on 1000's of agents installed inside our customers' locations (and on hardware that we don't own). Since LaunchDarkly uses server-sent events (SSE) this introduces no additional latency in making network calls to a central server. Changes to users and flags are sent streaming, seamlessly, behind the scenes, with minimal network impact. This key infrastructure decision that the team at LaunchDarkly made has given us confidence of using feature flags wherever we could feasibly imagine them without having any adverse impact to us or our customers. Oh, did you remember to build that into your homegrown FF solution?
- multivariate flags -- LaunchDarkly supports multivariate flags. For example, we throttle data transport for some of our remote agents. We can control this centrally so that certain agents only send back certain amounts of data (e.g. 1MB, 5MB, 10MB per batch of data sent). This actually extends the concept of FeatureFlags -- there are discrete variations within a single 'flag'. Don't forget to build that into your homegrown solution too.
- feature flag chaining -- you can specify a prerequisite for a feature flag. For example, for a rebranding of an entire website, you could have individual feature flags for each page, and then have a 'big bang' flag that does the entire thing at once. This allows you to test and manage 'micro features' but then turn on the 'major feature' easily.
- they have thought a lot about the technical debt that feature flags can introduce. How often have you added a feature flag only to not use it again or forget to remove it? It can make your code base ugly in a hurry. LaunchDarkly has analytics that help you identify usage paths as well as 'flag the flag' so you can be more conscious about what is a temporary vs permanent flag. This might not sound like much, but it prevents questions later about 'can we remove this flag' without causing impact. You've future proofed your homegrown solution to grow into this too, no doubt.
- organizational visibility and integrations with third party services -- LaunchDarkly has many integrations already built into it. For example, we use it to post to our #product channel in slack, so we can see when a new feature becomes available and when someone changes an existing flag/adds users to it. This has made communication about features much less time intensive because anyone can see the current state of a feature. You didn't really build a Slack integration or create a bot just for your homegrown feature flag service, did you?
If you think you'll eventually be in the place where what I've spoken about would be helpful, I would strongly suggest you consider a service like LaunchDarkly early in your development so that you can focus your energy on the right things and take advantage of the hard work that LD is putting into their service.