Feature Flag
A feature flag (also called a feature toggle) is a code-level toggle that lets engineering teams turn features on or off in production without redeploying. It is used for gradual rollouts, A/B tests, kill switches in case of incidents, and entitlement gating between paid plans, and is now a near-universal pattern in modern continuous-deployment environments. The concept was formalized in Martin Fowler's writing in the early 2010s and operationalized by platforms like LaunchDarkly, Split.io, Optimizely, and the open-source Unleash and Flagsmith.
The four common use cases: gradual rollouts (ship a feature to 1 percent of users, then 10, then 50, then 100, watching metrics at each step), A/B tests (route 50 percent of users to variant A and 50 percent to variant B, measure the difference), kill switches (turn off a broken feature immediately during an incident, without an emergency deploy), and entitlement gating (different plans see different features, controlled centrally rather than hard-coded). The structural shift feature flags enabled: separating deploy (code goes to production) from release (users see the change), which lets teams deploy continuously while still controlling user-facing change. The technical-debt risk: flags accumulate. A team that ships every feature behind a flag and never removes the flag after the feature is fully rolled out ends up with thousands of conditional branches in production code, none of which can be safely removed without risk. The discipline (advocated by Pete Hodgson's "Feature Toggles" essay on martinfowler.com, 2017) is to treat flags as inventory with explicit owners, expiration dates, and a regular cleanup cadence.
Ryan's Take
Feature flags are one of the best investments a product team makes and one of the most abused. The point is controlling the blast radius of a release. The abuse is leaving every flag in forever because nobody owns cleanup. A codebase with 500 live flags isn't a codebase anymore, it's a configuration database with runtime behavior no one can predict. Build expiration dates and a quarterly cleanup habit alongside the flag system itself, or year two is going to hurt.
What founders get wrong: Treating feature flags as a substitute for testing and discovery. Shipping a feature behind a flag does not validate that the feature is worth building; it just delays the moment when everyone has to look at the result. Use flags for control of rollout, not as cover for skipping the discovery work that should have happened before the flag was added.
Related: A/B Testing · Beta Testing · Product Launch · Agile
FAQ
What is a feature flag?
A code-level toggle that lets teams turn features on or off in production without redeploying the application. Used for gradual rollouts, A/B tests, kill switches during incidents, and entitlement gating between paid plans. Near-universal in modern continuous-deployment environments.
What are the main feature flag platforms?
LaunchDarkly (market leader), Split.io, Optimizely Full Stack, Flagsmith, ConfigCat, Statsig, GrowthBook (open source), and Unleash (open source). Most major product analytics platforms (Amplitude, Mixpanel) now also include flag functionality.
What is the risk of using feature flags?
Technical debt from flag accumulation. A team that adds flags but never removes them after rollout ends up with thousands of conditional branches in production code, none safely removable. The discipline is to treat flags as inventory with owners, expiration dates, and quarterly cleanup sprints.
Find this article helpful?
This is just a small sample! Register to unlock our in-depth courses, hundreds of video courses, and a library of playbooks and articles to grow your startup fast. Let us Let us show you!
Submission confirms agreement to our Terms of Service and Privacy Policy.