Feature Flagging

What Is Feature Flagging?

Feature flags (also called feature toggles) are the bridge between engineering and experimentation. They allow teams to deploy code to production without exposing it to all users, then gradually roll it out — first to internal testers, then to a percentage of users, then to everyone. Every modern A/B test is essentially a feature flag with measurement attached: the variant is "flagged on" for a random subset, and the platform measures the behavioral difference.

Beyond experimentation, feature flags enable instant rollbacks, canary deployments, and gradual rollouts — dramatically reducing deployment risk.

Also Known As

• Marketing: Feature gates, rollout controls
• Sales: Beta flags, customer-specific features
• Growth: Experimentation flags, rollout toggles
• Product: Feature toggles, release flags
• Engineering: Feature toggles, kill switches, config flags
• Data: Bucketing flags, assignment keys

How It Works

A product team wants to test a new onboarding flow. They wrap the new flow in a feature flag named "onboarding_v2_enabled". On deploy day, the flag is off — production behavior is unchanged. They enable the flag for internal employees first, catch two bugs, fix them, then enable for 5% of signups as an A/B test. After two weeks of positive data, they increment to 25%, then 50%, then 100% — with the ability to instantly roll back at any percentage if issues emerge.

The entire process requires zero additional deploys. Engineering shipped once; marketing, growth, and product control exposure independently.

Best Practices

• Use a managed feature flag platform (LaunchDarkly, Statsig, Split) rather than building custom infrastructure.
• Name flags descriptively and include the team owner and retirement date.
• Delete retired flags aggressively — orphaned flags create technical debt and rollout confusion.
• Use gradual rollouts for every production release, not just experiments.
• Log flag evaluations so you can debug "why did this user see variant B?" questions later.

Common Mistakes

• Building a custom flag system — the hidden complexity (consistent bucketing, targeting, analytics integration) almost always justifies a managed platform.
• Leaving dead flags in code — flag rot makes the codebase harder to reason about and can cause production incidents.
• Using flags for configuration that should be database-driven — flags are for behavior, not content.

Industry Context

SaaS/B2B: Feature flags are essential for enterprise rollouts where different customers need different capabilities. They also enable "dark launches" where new features run in production without being exposed.

Ecommerce/DTC: High traffic makes flag performance matter — evaluations must be fast and cached efficiently. Gradual rollouts reduce risk of site-breaking regressions on critical revenue paths.

Lead gen: Simpler sites often underinvest in flags, but even small sites benefit from kill switches on new landing pages and forms.

The Behavioral Science Connection

Feature flags reduce the psychological resistance to shipping changes by making every release reversible. This counters loss aversion — the fear that a bad release will cause disproportionate harm. When rollback takes seconds instead of emergency deploys, teams become more willing to ship bold changes, which accelerates learning.

Key Takeaway

If your organization doesn't use feature flags, it's the single highest-leverage investment you can make in experimentation infrastructure — the ROI comes through 2–3x higher test velocity per quarter.