Feature flags
FEE-cher flagz
Configuration toggles that control which features are active in production without deploying new code.
Feature flags are boolean switches that control whether a feature is visible or active in your application. They let you deploy code to production without exposing it to users. The code is there, sitting behind an if statement, waiting for you to flip the switch.
This decouples deployment from release. You can merge feature code to main, deploy it to production, and only enable it for 1% of users to test. If something goes wrong, you flip the flag off. No rollback needed. No hotfix. No emergency deploy. Just a configuration change that takes effect in seconds.
LaunchDarkly built a $3 billion company around this concept. But you can start simple. A JSON config file, an environment variable, or a database row that says "show_new_checkout: true." The complexity scales with your needs. Startups use environment variables. Enterprises use dedicated feature flag platforms with targeting rules, percentage rollouts, and audit logs.
Examples
A team gradually rolls out a new checkout flow.
The new checkout is deployed behind a feature flag. Week one: 5% of users see it. The team monitors conversion rates, error rates, and support tickets. Week two: the new flow shows 12% higher conversion. They increase to 25%, then 50%, then 100% over four weeks. The old checkout code is removed after the rollout completes.
A developer uses feature flags to work on an unfinished feature.
The feature is three sprints away from completion. The developer merges partial code to main behind a flag set to false. Other developers' work is not blocked by a long-lived feature branch. When the feature is complete, QA tests it by enabling the flag in staging. No merge conflicts from a three-week-old branch.
An infrastructure team uses flags for a database migration.
The team is migrating from PostgreSQL to CockroachDB. A feature flag controls which database handles reads. They start with 1% of read traffic going to CockroachDB, comparing results with PostgreSQL. When they confirm data consistency at 100% of reads, they flip a second flag to route writes. The entire migration happens without downtime.
In practice
Read more on the blog
Frequently asked questions
What is the difference between feature flags and environment variables?
Environment variables are set at deploy time and require a restart to change. Feature flags can be changed at runtime without redeploying. Environment variables work for simple on/off toggles per environment. Feature flags support targeting (enable for specific users), percentage rollouts, and instant toggling. Start with environment variables, graduate to a flag system when you need more control.
How do you prevent feature flag debt?
Every flag should have an owner and an expiration date. When a rollout completes, remove the flag and the old code path. Some teams enforce this with lint rules that flag (no pun intended) any feature flag older than 90 days. Track flags in a central registry. A codebase with 200 stale feature flags is just as hard to maintain as one with technical debt.
Related terms
The process of releasing code to servers where users can access it.
Gradually rolling out a new version to a small subset of users before making it available to everyone.
A deployment strategy using two identical environments to enable instant cutover and rollback.
The live environment where real users interact with the application.
Continuous integration and continuous deployment: automating code testing and delivery to production.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.