What Are Feature Flags and How Do Teams Use Them?

Your team finished a big feature on Tuesday, but marketing wants to announce it next month. Meanwhile, 5 other changes are waiting to ship. Do you hold everything back, or maintain a long-lived branch that gets harder to merge every day?

Feature flags solve this. They let you deploy code to production with the new feature switched off, then turn it on whenever you choose, for everyone or just a few users. Used well, they make releases calmer and rollbacks almost instant. Used carelessly, they leave a trail of forgotten switches that can cause serious bugs.

This guide explains how feature flags work, the main ways teams use them, and the habits that keep them from becoming debt.

What a feature flag actually is

At its simplest, a feature flag is a conditional in your code whose value you can change without redeploying. The OpenFeature project, an open standard for feature flagging hosted by the Cloud Native Computing Foundation, describes a flag as an if/else statement that can be controlled at runtime.

if (flags.isEnabled("new-checkout", user)) { showNewCheckout(); } else { showOldCheckout(); }

The value usually comes from a flag service or configuration store rather than being hard-coded. Most flag systems are also context-aware: the decision can depend on who the user is, which country they are in, which plan they pay for, or a random percentage bucket.

You will also hear feature flags called feature toggles, feature switches or release toggles. They all mean the same basic idea.

Deploy is not the same as release

The biggest benefit of feature flags is that they separate 2 events teams often treat as one:

• Deploy: putting new code onto production servers
• Release: letting users actually see and use the new behavior

Without flags, deploying is releasing. With flags, you can deploy many times a day with features hidden, then release on your own schedule. That makes practices like trunk-based development and continuous deployment much safer, because unfinished work can live in the main branch, switched off.

Key takeaway: Feature flags let you decouple deploying code from releasing features. That one change makes it possible to ship small changes often, release gradually and turn off problems in seconds, as long as you remove flags once they have done their job.

The 4 main types of feature flags

Not all flags are the same. Treating them differently is the first step to keeping them under control. The open source flag platform Unleash, for example, categorizes flags by purpose and gives each type an expected lifetime.

Unleash’s defaults suggest about 40 days for release and experiment flags, 7 days for operational flags, and no expiry for kill switches and permission flags. Your numbers may differ, but the principle holds: most flags should be temporary.

Release toggles

Release flags are the workhorse. Developers merge code behind a flag that is off by default. When the feature is ready, the team turns it on for internal staff, then a small percentage of customers, then everyone. If error rates rise, they turn it off without a rollback or hotfix.

This gradual rollout is similar to a canary deployment, but it happens at the feature level inside a single deployed version. Our comparison of blue-green vs canary deployments covers the infrastructure-level equivalents.

Experiments

Experiment flags randomly assign users to variants and record which variant each user saw. Combined with analytics, they let product teams measure whether a change actually improves sign-ups, conversion or engagement. The flag is only half the job here. You also need a clear metric, enough traffic, and a decision rule set before the test starts.

Kill switches and operational flags

Operational flags give on-call engineers a fast way to reduce load or shut off a misbehaving feature during an incident. A kill switch on a non-essential feature, like personalized recommendations, can keep the core product running when a dependency fails. These flags are worth testing regularly, because a kill switch nobody has flipped in a year may not work when you need it.

How teams roll out a feature with flags

A typical release with feature flags looks like this:

1. Create the flag with a clear name, owner, type and planned removal date. Default it to off.
2. Wrap the new code in the flag check, keeping the old path working.
3. Merge and deploy to production as normal through your CI/CD pipeline. Users see no change.
4. Turn it on internally for staff or test accounts and check behavior in production.
5. Roll out gradually, for example 1%, then 10%, then 50%, watching errors, latency and business metrics at each step.
6. Go to 100% once you are confident.
7. Remove the flag and the old code path, then delete the flag from your flag system.

Step 7 is the one teams skip. That is where flag debt begins.

Flag debt: the hidden cost

Every flag adds a branch to your code. Two flags create 4 possible combinations, and 10 flags create over 1,000. Tests rarely cover them all. Old flags also confuse new engineers, who cannot tell which paths are still live.

The worst case is a forgotten flag that gets reused or flipped by mistake. The best-known example is Knight Capital. According to the US Securities and Exchange Commission’s 2013 order, Knight left unused code called Power Peg in its trading system for years, and new code deployed in 2012 repurposed a flag that had formerly activated it. The new code reached 7 of 8 servers. On the eighth, the repurposed flag triggered the old logic. The SEC says Knight sent more than 4 million orders in about 45 minutes and lost over $460 million.

Not every stale flag will cost that much, but the lesson is clear: dead code behind a flag is still code that can run. Our guide to technical debt covers how small shortcuts like this compound over time.

Cleanup habits that prevent flag debt

Teams that use flags heavily build cleanup into the process, not into good intentions.

Unleash, for instance, automatically marks flags as potentially stale once they pass their expected lifetime and warns against reusing names of deleted flags, because old code may still reference them.

Build or buy a feature flag system

You can start with a configuration file or environment variables, but that only works for simple on and off switches. Once you need percentage rollouts, user targeting, audit logs and instant changes without restarts, most teams use a dedicated tool.

The OpenFeature standard offers a vendor-neutral API, so your application code calls one interface while the provider behind it can change. That reduces lock-in if you later switch tools.

Where to start

1. Pick one upcoming feature and put it behind a single release flag.
2. Agree on a naming and ownership convention before you create a second flag.
3. Choose a tool that matches your scale. A config-based switch is fine for a first trial; move to a flag service once you need gradual rollouts.
4. Add flag removal to your definition of done so a feature is not finished until its temporary flag is gone.
5. Measure the effect. Track deployment frequency and change fail rate with DORA metrics to see whether flags make releases safer.

Conclusion

Feature flags are one of the simplest ways to make releases less stressful. They let you ship small changes continuously, test with real users, and turn off problems instantly. Their only real downside is the debt they leave behind, and that is a habit problem, not a tooling problem. Give every flag an owner and an end date, and they stay an asset.

Sources

• OpenFeature documentation — definition of feature flags and the vendor-neutral flagging standard (CNCF incubating project)
• Unleash documentation: feature flags — flag types, expected lifetimes and stale flag handling
• SEC press release 2013-222 — Knight Capital losses, order counts and the unused router code
• SEC order: Knight Capital Americas LLC — repurposed flag that activated the old Power Peg code