I 100% agree with everything you said and more. I spent a significant amount of time at my job arguing constantly with the entire engineering department that “Feature Flags” are not all the same thing and had to push back on efforts to mix them all up.

Examples:

Experiment flags for A/B testing

Permission checks at a user level

Product flags for feature gating by plan

Rollout flags to launch a new feature gradually

Configuration for an account/system/feature

The number of times I had to push against the “just put it behind hasFeatureFlag(user, flag)” is more than I can count at this point! I think it comes from a misunderstanding of the DRY principle, to be honest.

▲

esafak an hour ago | parent [-]

Why would you not use the same service to handle them? Less is more.

	▲	hasyimibhar 20 minutes ago \| parent [-]
		Having worked at a large company that misuses feature flag service for everything, here are some examples why you shouldn’t: - one team uses feature flag for product gating. Feature flag service goes down. Users temporarily got locked out of the features they paid for. - one team uses feature flag for dynamic pricing by leveraging targeting rules (how hard is it to write a bunch of if else in code?). It’s evaluated against all users, even if they are not active (for analysis reasons). Feature flag service charges by MAU. We have millions of users. Our feature flag service bill is now 6 digits per year. - one team uses feature flag as literal json store instead of a proper db (god knows why). Someone updated the value but the “schema” is wrong. Shit breaks.