Current version : 0.23.0
Made in 🇫🇷 ◌ GitHubNPM

Feature Flags as a Feature

What if we let the users of our apps manage the Feature Flags by themselves ?

PostHog, LauchDarkly... the offer of tools to manage Feature Flags (a.k.a FFs) is plethora.

Most of these tools are used to :

  • Enable a feature only when it's ready (e.g. trunk based development)
  • Enable a feature only to some users (e.g. QA)
  • Enable a feature only to some types of users (e.g. country based segmentation)
  • Enable a feature only to a portion of the users (e.g. A/B tests, progressive rollout)

All these use cases are "internal" and/or "technical".

But what about our users ? Why don't we use FFs to let them "Enable a feature only if I want it".

Pause reading here, and take the time to look at the tools you use daily. How many UI controls do you see, that you have never, absolutely never touched ? Yet, they are here in the UI, taking some precious real estate that could be used for something else.

For instance, with the advent of "AI", products have started integrating half baked "Copilot" things, forced to enabled for everyone.

Take Visual Studio Code as an example. Some people do not use "Copilot", "Agents" or anything of this kind. Let us disable it !

And it's not just AI. Every mobile app bothers you with things you absolutely don't need. No matter how hard they try (annoying push notifications, useless space taken in the UI), some people use Uber only for rides, never for Uber Eats. Let us disable it !

The list of examples is endless.

You might argue that it's often possible to disable them in some deeply nested menu. But this is not the way to do it properly.

Also, you might argue that it breaks "discoverability". Indeed, new features rollout need to be thoroughly re-thought. It's not really that hard to communicate in this way :

Hey, here is our new feature. Do you want to use it ? [y/N].

Plus, it would be interesting to evaluate the churn rate caused by product bloat.

In the end, what if, as an industry, we generalize and commoditize a "Features Menu" where anyone can pick and choose what they want ? Obviously, we might need to "internalize" the FFs management and stop using the tools listed at the beginning of this article. But is it that hard to store a record per user having this kind of shape :

type FeatureCode = string;
type UserPreferences = Record<FeatureCode, boolean>;

Not really.

In this "AI era", everyone talks about bespoke software. But we are probably over-thinking it.

What if we start simple with a "Features Menu" and give more choice to the user ?