Feature flags — shipping code without shipping the feature
Deploying code and releasing a feature are usually treated as the same event. A feature flag is the small mechanism that splits them apart — and once they're split, a whole class of risky release problems gets a lot smaller.
Beginner
2 min read
Two decisions that don't have to happen at the same time
Normally, "merge and deploy this code" and "users can now see this feature"
are the same moment — the deploy is the release. A feature flag is a
simple runtime check (usually just an if) that lets a team separate those
two decisions:
if feature_flags.is_enabled("new_checkout_flow", user): return render_new_checkout()return render_old_checkout()
The new code can be merged, deployed, and running in production — completely
inert for every user until the flag is switched on. Turning the feature on
becomes a fast, reversible configuration change instead of a new deployment.
What this actually buys you
Deploy on your schedule, release on a different one. Code can be
merged and deployed the moment it's ready, without forcing a "launch day"
to line up with a deploy — the two become independent decisions.
Half-finished work-in-progress can even sit behind a flag in production
for weeks without being visible to anyone.
Instant rollback without a redeploy. If a released feature causes a
problem, flipping the flag back off is a fast, low-risk configuration
change — much faster than reverting a deploy, especially if other commits
have landed since.
Gradual rollout. A flag can be enabled for 1% of users, then 10%, then
everyone — catching a real production problem while it only affects a
small fraction of users, rather than everyone at once.
Testing in production, safely. An internal team can have a flag turned
on for themselves specifically, trying a feature against real production
data and traffic before it's ever visible to a real user.
The real cost: flags accumulate
Feature flags aren't free — every flag is a branch in the code that has to
be maintained, and a codebase littered with year-old flags nobody remembers
the purpose of becomes its own kind of technical debt (the earlier lesson on
technical debt applies directly here). The discipline that makes flags worth
it long-term is removing them once a feature is fully released and stable —
deleting the flag and the old code path it used to switch between, not
leaving both branches sitting there indefinitely.
Why this matters day to day
Feature flags are one of the more direct, practical tools available for
reducing the risk of shipping — they turn "did this deploy break
production" into a smaller, faster-to-answer question, and turn "we need to
revert" into a configuration flip instead of a rushed rollback under
pressure.