A feature flag is essentially a key → value (usually boolean) pair that decides whether a capability is active. In code it’s an ordinary condition: if the flag is on, the new logic runs; if off, the old behaviour stands. Flags let you hide unfinished features behind a condition and roll them out to an audience gradually.
Early on, flags are almost always done “locally” — an environment variable, a constant or a config parameter. In a small project that honestly works and nothing better is needed. The trouble starts at the scale of a team and many environments.
First, changing a local flag usually needs a new deploy, so the ability to “flip the switch on the fly” is lost — and with it half the point of flags. Second, environments drift: in prod the feature is on via one config, in the test build it’s off by default, and testers reconcile the two by hand. Third, nobody sees the whole picture: which flags exist, who touched them and when, and which are long overdue for deletion.
A centralised flag-management platform (like Unleash) removes exactly this pain. Flags live in one place with a web UI; values change at runtime with no deploy at all; there are rollout strategies, targeting by user attributes and a full change history with author and timestamp.
Technically it works like this: the application embeds an SDK that periodically pulls the flag configuration and evaluates values locally — fast and with no network round-trip per request. In code the developer simply asks “is flag X on for this user?”, while all the rollout logic (to whom, what percentage, by which rules) lives outside the code and changes with no release.
A separate topic is flag hygiene. A centralised approach not only makes turning things on easier — it makes the stale visible: the platform flags “dead” toggles that have long been at 100% and only clutter the code. The rule is simple: every flag has an owner and an expected lifetime.
I covered the full version, with code examples and a breakdown of strategies, in an article on Habr — link below.