Feature flag: plainly explained.

A feature flag (also called a feature toggle) is a conditional in the code that decides whether a feature is visible or active. The team can change its value from a dashboard or a config file, without shipping a new version. A feature can therefore be deployed to production while staying hidden until the team is ready to release it.

The idea separates two moments that used to be tied together: deploying code and releasing a feature to users. That separation reduces risk and makes releases much calmer.

The application asks a flag service, or reads a config value, whether a feature is enabled for the current user. The answer decides which code path runs.

if (flags.isEnabled('new-checkout', user)) {
renderNewCheckout();
} else {
renderOldCheckout();
}

Flags can be evaluated on the server or in the browser, and their value can depend on the user, the country, the plan or a random percentage of traffic.

• Release flags: hide unfinished work and allow gradual rollouts.
• Experiment flags: split traffic between variants for A/B tests.
• Ops flags: act as a kill switch to disable a heavy or failing feature quickly.
• Permission flags: reserve a feature for a plan, a beta group or internal users.

• Give each flag a clear name, an owner and an expected removal date.
• Remove a flag as soon as the feature is fully released, otherwise it becomes technical debt.
• Keep the number of active flags low and test both the on and off paths.
• Default to the safe state if the flag service does not respond.
• Log which flag values a user saw, to make bugs reproducible.

Flags fit naturally into automated workflows: a webhook can flip a flag, and a rollout can be staged without a new deployment. Through our automation services, our team connects flags, alerts and release steps so that launches stay controlled and easy to reverse.