Types of Feature Flags

You thought feature flags were just on/off switches? Cute. As it turns out, the industry has spent years categorizing exactly how many ways you can wrap an if statement. Martin Fowler identified at least four main types, and you can bet someone’s added more since then. (martinfowler.com)

Release Toggles

These are the workhorses. A release toggle hides an unfinished feature from users while it’s still being built. The code ships to production, but no one can see the new checkout flow because the flag is off. When the feature is done and tested, flip the switch. This is the flag type that makes continuous delivery actually possible without shipping half-baked work to the entire user base.

Keep release toggles short-lived. They’re not meant to be permanent fixtures. Set a reminder to delete them once the feature is fully rolled out, or your codebase will haunt you.

Experiment Toggles

Experiment toggles are for A/B testing. You want to show version A of the landing page to half your users and version B to the other half, then measure which one makes people actually click the button. The flag controls which group a user falls into, and your analytics tell you who won.

These flags can get complicated fast. You need consistent assignment (a user should always see the same variant), and you need to clean them up when the experiment concludes. Otherwise, your codebase becomes a museum of hypotheses nobody remembers testing.

Ops Toggles

Ops toggles are your emergency brake. They’re designed to let you turn off expensive or risky features in a hurry — without a redeployment. Degraded-mode functionality, rate limiting, disabling a third-party integration that’s melting down — ops toggles handle all of this.

Unlike release toggles, ops toggles are often meant to stick around. They’re the kill switches that let your on-call engineer sleep at night, knowing they can flip one flag to stop the bleeding while the real fix is being written.

Permission Toggles

Permission toggles gate features by user role, subscription tier, or account status. Beta users get the new feature. Enterprise customers get the advanced reporting. Free tier? You get to look at a screenshot. It’s capitalism with a configuration file.

These are longer-lived by design and often tie directly into your authorization logic. Be careful about letting them sprawl — if every feature has its own permission toggle, you’ll need a spreadsheet just to understand what any given user can see. A flag management UI keeps this sane by letting you view and control all your permission toggles in one place, without digging through config files or paging through code.

Picking the Right Type

The short version:

• Release Toggles: Shipping unfinished work safely. Temporary.
• Experiment Toggles: A/B testing and experimentation. Temporary.
• Ops Toggles: Emergency switches and circuit breakers. Often permanent.
• Permission Toggles: Feature access by user tier. Often permanent.

The more types you add, the more likely you’ll forget what any of them do. Document everything, assign owners, and have a plan to clean them up.

You asked for one boolean. You got a taxonomy. Welcome to software.