Feature Flags
Updated June 8, 2026Imagine you are building a new roller coaster at a theme park. It takes months to build. You wouldn't wait until the entire track is perfectly finished before laying the first piece of steel. You build it piece by piece, right there in the open.
But you definitely don't want guests trying to ride it while it's half-finished. So, what do you do? You put up a massive fence with a locked gate. The coaster is there, physically in the park, but no one can access it.
In software engineering, that locked gate is called a Feature Flag (or Feature Toggle).
What are Feature Flags?
A feature flag is a technique that allows you to turn a feature in your application on or off without deploying new code.
At its core, a feature flag is just a fancy if statement wrapped around your code:
if (featureFlags.isNewCheckoutEnabled()) {
// Show the shiny new checkout flow
renderNewCheckout();
} else {
// Show the old, boring checkout flow
renderOldCheckout();
}Instead of hardcoding true or false, the value comes from an external source: a database, a config file, or a specialized service like LaunchDarkly. You can toggle this value from a dashboard in real-time.
Decoupling Deployment from Release
This simple concept solves one of the biggest headaches in software development. It fundamentally separates Deploying from Releasing.
- Deployment is the technical act of moving code to a production server.
- Release is the business act of exposing a new feature to end users.
Historically, these two things happened at exactly the same time. If marketing wanted to launch a new feature on Tuesday at 9 AM, engineers had to frantically push code at 8:59 AM and pray it worked.
With feature flags, you can deploy the code three weeks early. The code sits dormant in production behind a flag set to false. On Tuesday at 9 AM, a Product Manager logs into a dashboard, clicks a button to turn the flag to true, and the feature is instantly live. No stress, no risky morning deployments.
Flag = false: app serves old checkout. | Flag = true: same code, same server, same deploy — but the flag evaluation routes to the new checkout. No redeployment required.
Real-World Superpowers
Feature flags unlock incredibly powerful workflows for engineering teams.
1. Trunk-Based Development
Long-lived feature branches are a nightmare. If you spend two months building a feature on a separate Git branch, merging it back into main will result in horrible merge conflicts.
With feature flags, you merge incomplete, half-broken code into main every single day. Because it's hidden behind a flag, it won't break production. This allows teams to iterate quickly and avoid "merge hell."
2. Kill Switches
If you launch a new search algorithm and suddenly the database CPU hits 100% and the site is crashing, you don't need to write a hotfix, run tests, and redeploy. You just hit the kill switch on your dashboard. The flag flips to false, the old algorithm takes over, and the site recovers in seconds.
3. Targeted Rollouts & Beta Testing
Flags don't have to be just true or false. They can be conditional. You can configure a flag to evaluate to true only if:
- The user is an internal employee.
- The user is in the "Beta Testers" group.
- The user's ID ends in an even number (a simple way to roll out to 50% of users).
Netflix and Chaos Engineering
Netflix uses feature flags extensively. They can completely disable non-critical features (like personalized recommendations) during a severe outage to free up server resources for core video streaming. This pattern is known as a "bulkhead" or "graceful degradation."
The Dark Side: Flag Debt
Feature flags are amazing, but they introduce a new problem: Technical Debt.
Every feature flag creates two alternate realities in your code base. If you have 10 active flags, you have 1,024 different possible states your application could be in. Testing all of them is impossible.
Furthermore, once a feature is 100% rolled out and stable, the flag becomes useless. If you forget to delete the old if/else block, your codebase will slowly fill up with dead code. In 2012, a dormant, reused feature flag at Knight Capital Group accidentally triggered dead trading code, losing the company $460 million in 45 minutes.
[!WARNING] Treat feature flags as temporary. Create a Jira ticket to remove the flag on the exact same day you create the flag. Keep your codebase clean!
Summary
Feature flags wrap new code in a remote-controlled if statement, decoupling code deployment from feature release. They enable stress-free launches, instant kill switches, and targeted rollouts. Clean them up when the rollout is done. Old flags left in the codebase are a recipe for confusion and, as Knight Capital proved, very expensive bugs.
How helpful was this content?
Comments
Sign in to join the discussion
Saved on this device only
Sign in to sync progress across devices