Feature Flag.

A feature flag (also called a feature toggle) separates two things that coincide in traditional software development: shipping code and switching on a feature. The new code is already on the server, but a simple check decides whether it runs. The value of that switch lives outside the code, for example in a configuration file, an environment variable, a database table or a dedicated service. Flipping it changes the application's behaviour immediately, without a new build and without a new deployment.

There are roughly four kinds. Release flags hide unfinished features so the team can keep working on the main branch of version control instead of maintaining separate branches for weeks. Experiment flags split users into groups and are the technical basis for A/B testing. Ops flags are kill switches that turn off a resource-heavy or fragile feature under load. Permission flags enable features only for certain customers, plans or roles, such as an export that is only included in the larger subscription.

The biggest practical benefit is gradual release. A new feature first runs only for internal accounts, then for five per cent of users, then for everyone. If errors show up, nobody rushes a rollback; the switch is simply flipped. That lowers the risk of every release and allows shipping more often in smaller steps. Combined with a staging environment, the result is a calm process: test on staging, ship to production behind the flag, release in a controlled way.

Feature flags have a downside: every switch doubles the paths the code can take. If old flags are not removed after full release, the number of possible combinations grows, tests become confusing and nobody knows which switch still does anything. That is a typical form of technical debt. Good practice is therefore to give every release flag an expiry date and an owner when it is created. How we build web apps with a clean release process is described on the page web app development.