Feature Flags

Traditionally, deploying code and releasing a feature were the same event. If the code reached production, users saw it, so teams held finished work back until everything was ready and tested together, then released it all at once and hoped for the best. Feature flags break that link. A flag wraps new functionality in a condition that can be switched on or off while the software is running. Code can be deployed to production in a dormant state, turned on for internal users, then for a small share of customers, then for everyone, and switched off instantly if something goes wrong. The decision about who sees a feature moves from deployment time to run time, where it can be changed in seconds.

Feature flags, also called feature toggles, have been used at large web companies for many years. Pete Hodgson's article on feature toggles, published on Martin Fowler's website in 2016, described the main types and the discipline needed to manage them. Today, flags are often managed through dedicated platforms that let product and engineering teams control releases without code changes. For developers, product managers and release managers, feature flags make frequent deployment safe and give the business direct control over when users see new features.

Definition of Feature Flags

Feature flags are conditional controls in software, managed through configuration or a flag management service, that determine at runtime whether a feature or code path is active for a given user, group or environment, without requiring a new deployment.

They make trunk-based development practical, enable gradual rollouts such as canary deployment and support continuous delivery by separating deployment from release.

Types of Feature Flags

Release flags hide unfinished or untested features in production until they are ready. They should be short-lived and removed once the feature is fully released.

Experiment flags show different versions of a feature to different groups of users to measure which performs better, as in A/B testing.

Operational flags let teams turn off expensive or risky functionality during incidents or heavy load. A kill switch is a common example.

Permission flags enable features for specific customers, plans or user groups, such as beta programs or premium tiers, and may last a long time. Knowing which type a flag is matters, because it determines how long the flag should live and who is allowed to change it.

How Flags Are Targeted

Flags can be turned on for everyone, no one or specific groups, such as internal staff, beta customers or users in one region.

Percentage rollouts expose a feature to a growing share of users, such as 1%, then 10%, then 100%.

Targeting rules are evaluated at runtime, so changes take effect within seconds without a deployment. Flag values are usually cached by the application, so the flag service being slow or unavailable does not stop the application from working.

Importance of Feature Flags in Delivery and Engineering Operations

Feature flags reduce release risk. Problems can be contained by turning a flag off in seconds instead of rolling back a deployment.

They enable frequent deployment. Unfinished work can be merged and deployed safely, so teams no longer need long-lived branches or large batch releases.

They also give the business control over timing. Product and marketing teams can launch features when it suits customers and campaigns, independent of engineering deployment schedules. Flags also support learning. Experiment flags let teams measure how a change affects user behavior before committing to it fully.

Feature Flags and Financial Management

Turning off a failing feature quickly limits lost revenue and incident costs.

Experiment flags let teams measure the business impact of features before full rollout, avoiding investment in changes that do not perform.

Operational flags can switch off costly functionality, such as heavy AI or data processing features, when budgets or capacity are under pressure.

Flag management platforms carry license costs, and old flags add maintenance effort, so both should be managed actively.

Common Challenges

Flags that are never removed accumulate as technical debt, making code harder to read and test. Every release flag needs an owner and a removal date.

Many flags in combination create many possible states, which complicates testing. Teams should test the combinations that matter most.

Flag changes can cause incidents just like code changes, so they need access controls, audit logs and monitoring. Relying on flags to hide incomplete security or data changes is risky, since a misconfigured flag can expose them. Some changes should not be deployed until they are ready.