What it is
A feature flag is a name in your code that points at a value kept outside the code. The app asks for that value at runtime, gets true or false, or a variant name, and takes one branch or another. The branch that ships dark sits behind the flag until someone turns it on.
Teams use flags for a few different jobs, and it helps to name them by job. A release flag hides unfinished work until it is ready. An experiment flag splits traffic between variants so you can compare behavior. An ops flag, sometimes called a kill switch, lets you turn off a heavy or failing feature without a deploy. An entitlement flag controls who has paid for what, and that one is meant to live for years.
Only the first three are temporary. That distinction matters, because most flag mess comes from treating a release flag like an entitlement flag and never taking it out.
How it works
Most setups have a small service that stores flag definitions plus an SDK in each app. The SDK caches the rules, evaluates locally and refreshes in the background, so a flag check costs almost nothing at request time. The definition holds a key, a default value, targeting rules and a list of variations.
Targeting is where flags earn their keep. You can turn a flag on for a list of user IDs, an email domain, a country, a plan tier or a percentage of traffic. Percentage rollouts work best when the bucketing key is stable, such as the account ID. The same account then lands in the same bucket on every request, so users do not flip between variants.
Server side evaluation is the safer default. If the browser or mobile app evaluates flags, the rules and any hidden feature code ship to the client, and someone can read them. Client side evaluation is fine for cosmetic tests and for flags whose values are not sensitive.
Every flag you add is a second code path. Two flags in the same function make four paths. That is the whole reason flags need a cleanup habit, and it is why a flag key should be read in one place per feature, not scattered across ten files.
Why it matters for a business
Flags separate deploy from release. You can merge and ship code on a Tuesday morning with the feature off, turn it on for a pilot customer, then widen the rollout. If something breaks, you flip the flag off in seconds instead of running a rollback, and the fix can wait for a normal release.
That speed changes how teams plan. Marketing can pick the launch hour. Support can get a head start on the docs. Finance can watch a new billing feature go live for one plan before it reaches everyone.
The other side is cost. A flag that stays after the rollout is finished is a branch nobody tests, a rule nobody remembers and a value that can still be flipped by mistake. Old flags are also a quiet security problem. A flag hiding an admin tool or a debug endpoint is a door someone forgot to lock. And when a customer asks why their account behaves differently, a forgotten flag is one of the first things an engineer has to rule out.
Common mistakes
The most common mistake is creating flags with no owner and no end date. A flag should be born with a name, a description, an owner and a removal date written into the flag definition itself, not into a wiki page.
The second is using a flag where a config setting belongs. Timeouts, page sizes, rate limits and copy strings should be settings, not branches. If both states of the flag will be supported forever, it is not a release flag, and it should not be managed like one.
The third is testing only the on state. Suites that run with flags defaulted to on leave the off path untested, and the off path is what customers see when something goes wrong. Run the suite with flags off, and with the defaults your production config uses.
The last is leaving the check in twenty places. One function should ask the flag, and the rest of the code should take a plain argument. When the flag dies, you delete one line.
How to get started
Start with one flag service or a database table and a thin wrapper in each app. The tool matters less than three fields being mandatory at creation: owner, description, expiry date. Add an audit log for who changed what, because you will want it during a customer security review.
Then write a removal checklist and use it every time. When a rollout reaches one hundred percent and holds for a set period, delete the flag from the code, delete the losing branch, delete the flag definition, and remove the tests that only existed for the old path. Do it in the same release that finishes the rollout, while the context is fresh.
Make cleanup visible. A weekly job that lists flags past their expiry date, posted where the team will see it, beats a policy nobody reads. A search for the flag key in the repo confirms the code side is clean.
If your release process still leans on one person, or flags would be a patch over a missing pipeline, a platform build can come first. Cloudverg's Delivery platform setup, a fixed price of $14,500 over four weeks, covers pipelines, separate environments, secrets, monitoring and a tested rollback. Flags work best on top of that.
Frequently asked questions
How is a feature flag different from a config setting?
A flag picks between code paths, so one of them is usually meant to be deleted. A setting tunes a value that stays, like a timeout or a page size. If both states need to live forever, treat it as configuration.
How long should a feature flag stay in the code?
For release flags, days to a few weeks: long enough to finish the rollout, check metrics and handle a rollback. Experiment flags live until the test is decided. Entitlement flags stay, and they should be managed like a product catalog.
Do feature flags slow down the app?
Local evaluation from a cached ruleset costs very little, far less than a network call per check. The real cost is in code complexity, not CPU. Keep one evaluation per request or per job and pass the result down.