Feature Flags
Feature flags (also called feature toggles) are a software development technique that lets a specific piece of code or functionality be turned on or off at runtime — without a new deployment — typically via external configuration.
Definition
Feature flags (also called feature toggles) are a software development technique that lets a specific piece of code or functionality be turned on or off at runtime — without a new deployment — typically via external configuration.
Overview
Feature flags introduce a conditional check in code, gating a code path behind a named flag whose value (on/off, or a more granular variant) is evaluated at runtime, often by querying an external configuration source rather than being hard-coded. This decouples the act of deploying code (getting it running in production) from the act of releasing a feature (making it visible or active for users), which is a foundational enabler of trunk-based development and continuous delivery: incomplete or risky code can be merged into the main branch and shipped to production while remaining invisible or inactive, then activated later without any further deployment. Feature flags serve several distinct purposes, often categorized (following Pete Hodgson's widely cited taxonomy) as: release toggles, which hide in-progress features until they're ready; experiment toggles, used to run A/B tests by serving different code paths to different user segments; ops toggles, which act as operational kill switches to quickly disable a problematic feature under load or failure without a rollback deployment; and permission toggles, which enable functionality for specific user segments such as beta testers, internal staff, or premium-tier customers. At small scale, flags can be implemented as simple environment variables or config values. At larger scale, dedicated feature-flag management platforms (LaunchDarkly, Split, Unleash, Flagsmith, and cloud-provider offerings like AWS AppConfig) provide a control plane for defining flags, targeting specific user segments or percentages of traffic, real-time toggling without redeploying, and auditing who changed what flag and when. A well-known operational risk of feature flags is 'flag debt' — flags that are never cleaned up after a feature fully ships accumulate over time, adding branching complexity, increasing the combinatorial number of code paths that need testing, and eventually becoming a source of confusing, hard-to-trace bugs; disciplined teams treat flag removal as a required step of the feature-shipping process, not an optional cleanup task.
Key Concepts
- Gates code paths behind a runtime-evaluated flag rather than a hard-coded branch
- Decouples code deployment from feature release/activation
- Categorized into release, experiment (A/B test), ops (kill switch), and permission toggles
- Enables trunk-based development by hiding in-progress work on the main branch
- Supports gradual rollouts to percentages of traffic or specific user segments
- Ops toggles act as instant kill switches without requiring a rollback deployment
- Managed at scale via dedicated platforms (LaunchDarkly, Split, Unleash, Flagsmith)
- Prone to 'flag debt' if flags aren't removed after a feature fully ships
Use Cases
Frequently Asked Questions
From the Blog
Feature Engineering: Turning Data Into Signal
Feature engineering turns raw columns into inputs a model can actually learn from. Learn the core techniques that often matter more than the algorithm itself.
Read More Data ScienceWhat Is Feature Engineering in Machine Learning?
Feature engineering is transforming raw data into inputs that help models learn. Good features often matter more than the algorithm. Learn the core techniques here.
Read More Data ScienceWhat Is Feature Scaling in Machine Learning
Feature scaling puts numeric inputs on a comparable range so no single feature dominates a model. Learn normalization, standardization, and when each matters.
Read More Data ScienceA Practical Feature Engineering Playbook for Tabular Data
Feature engineering for tabular data is best organised by data type and model family, with a validation loop that proves each feature earns its place. Learn how to treat numeric, categorical, temporal and event data differently, avoid leakage, and decide which transformations gradient-boosted trees genuinely need versus which only linear models do.
Read More