Feature Flags Done Right: Beyond the Toggle

Feature flags seem simple: wrap code in an if statement, flip a boolean, ship whenever you want. In practice, they’re one of the fastest ways to accumulate invisible technical debt. Here’s how to get the benefits without the baggage.

Why Feature Flags Matter

The core value proposition is decoupling deployment from release:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# Without flags: deploy = release
def checkout():
    process_payment()
    send_confirmation()

# With flags: deploy when ready, release when confident
def checkout():
    process_payment()
    if feature_enabled("new_confirmation_flow"):
        send_rich_confirmation()
    else:
        send_confirmation()

This separation enables:

Continuous deployment without continuous anxiety
Gradual rollouts to catch issues early
Quick rollbacks without redeploys
A/B testing with the same codebase

The Flag Lifecycle

Every feature flag should have a planned death:

Flags that live forever become landmines. Set expiration dates from day one.

Types of Flags (They’re Not All the Same)

Release Flags — Short-lived, gate new features during rollout

1
2
3
if feature_enabled("checkout_v2"):
    return new_checkout()
return old_checkout()

Lifespan: Days to weeks. Remove after full rollout.

Experiment Flags — A/B tests with metrics

1
2
3
4
5
variant = get_experiment_variant("pricing_test")
if variant == "control":
    show_standard_pricing()
elif variant == "higher_anchor":
    show_anchored_pricing()

Lifespan: Weeks. Remove after statistical significance.

Ops Flags — Circuit breakers and kill switches

1
2
3
if feature_enabled("enable_external_api"):
    return call_external_api()
return cached_fallback()

Lifespan: Permanent, but should be rare.

Permission Flags — User-level access control

1
2
if user_has_feature("beta_access"):
    show_beta_features()

Lifespan: Permanent, but this is entitlements, not feature flags.

Mixing these types in one system causes confusion. Label them.

Implementation Patterns

The Naive Approach (Don’t Do This)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# Scattered flags everywhere
def some_function():
    if config.get("new_thing"):
        # 50 lines of new code
    else:
        # 50 lines of old code
        
def another_function():
    if config.get("new_thing"):
        # different behavior

Problems: Flags leak everywhere, removal requires surgery, testing is combinatorial nightmare.

The Better Approach: Strategy Pattern

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
class CheckoutStrategy:
    def process(self, cart): ...

class LegacyCheckout(CheckoutStrategy):
    def process(self, cart):
        # old implementation
        
class NewCheckout(CheckoutStrategy):
    def process(self, cart):
        # new implementation

def get_checkout_strategy(user) -> CheckoutStrategy:
    if feature_enabled("checkout_v2", user):
        return NewCheckout()
    return LegacyCheckout()

Benefits: Flag check in one place, implementations isolated, easy to test, trivial to remove.

Flag Evaluation: Context Matters

Don’t just check if a flag is “on.” Evaluate with context:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
def feature_enabled(flag: str, context: dict = None) -> bool:
    """
    Context can include:
    - user_id: for percentage rollouts
    - user_attributes: for targeting
    - environment: for env-specific behavior
    """
    flag_config = get_flag_config(flag)
    
    # Check kill switch first
    if flag_config.get("force_off"):
        return False
    if flag_config.get("force_on"):
        return True
    
    # Percentage rollout based on user
    if context and "user_id" in context:
        bucket = hash(context["user_id"]) % 100
        return bucket < flag_config.get("rollout_percentage", 0)
    
    return flag_config.get("default", False)

Consistent bucketing matters—users shouldn’t flip between experiences.

The Cleanup Problem

The hardest part of feature flags is removing them. Here’s a system that works:

1. Track creation date and owner

1
2
3
4
5
6
7
flags:
  checkout_v2:
    owner: payments-team
    created: 2026-02-15
    expires: 2026-03-15
    description: "New checkout flow with Apple Pay"
    jira: PAY-1234

2. Alert on expiration

1
2
3
4
def check_flag_expiration():
    for flag in get_all_flags():
        if flag.expires < today():
            alert(f"Flag {flag.name} expired! Owner: {flag.owner}")

3. Make removal easy

1
2
3
4
5
6
7
8
# Generate removal PR automatically
./scripts/remove-flag.sh checkout_v2

# Creates PR that:
# - Removes flag from config
# - Removes all flag checks from code
# - Removes the "off" code path
# - Updates tests

4. Measure flag count

Track total active flags as a metric. Set limits per team. Flag count going up? That’s a code smell.

Testing with Flags

Feature flags multiply test scenarios. Be strategic:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
# Test the flag evaluation logic
def test_rollout_percentage():
    assert feature_enabled("test", {"user_id": "a"}) == True  # bucket 23
    assert feature_enabled("test", {"user_id": "b"}) == False # bucket 67

# Test each code path independently
def test_legacy_checkout():
    with flag_override("checkout_v2", False):
        result = checkout(cart)
        assert result.uses_legacy_flow

def test_new_checkout():
    with flag_override("checkout_v2", True):
        result = checkout(cart)
        assert result.uses_new_flow

# Don't test the combinatorial explosion
# Focus on: flag off, flag on, rollout logic

Common Pitfalls

Nested flags

1
2
3
4
5
# Nightmare to reason about
if feature_a:
    if feature_b:
        if feature_c:
            # which combination are we testing?

Solution: Flatten or create explicit compound flags.

Flag in the wrong layer

1
2
# Flag in the UI, but affects business logic
<Button onClick={featureEnabled ? newAction : oldAction} />

Solution: Flag at the domain layer, not presentation.

Stale percentage rollouts

1
2
# Rolled out to 50% six months ago, never finished
rollout_percentage: 50

Solution: Alerts on flags stuck between 0 and 100.

Testing against production flags

1
2
# Tests pass locally, fail in CI, work in prod
if feature_enabled("thing"):  # different in each env

Solution: Explicit test configuration, mock flag service in tests.

Tooling Options

Simple (config files)

1
2
3
4
# flags.yaml
checkout_v2:
  enabled: true
  rollout: 100

Good for: Small teams, simple needs, full control.

Medium (database-backed)

1
2
3
4
5
6
CREATE TABLE feature_flags (
    name VARCHAR PRIMARY KEY,
    enabled BOOLEAN,
    rollout_pct INT,
    expires_at TIMESTAMP
);

Good for: Dynamic updates, audit trails, moderate scale.

Full platform (LaunchDarkly, Split, etc.)

Real-time updates
Targeting rules
Analytics
Audit logs

Good for: Large teams, complex rollouts, experimentation programs.

Pick based on your needs. Starting simple is fine—you can always migrate.

The Meta-Rule

Feature flags are a liability, not an asset. Every flag is:

Code that might run
Code that might not run
A test you need to write
A decision someone needs to make
Debt that accrues interest

Use them when the value exceeds the cost. Remove them the moment they’ve served their purpose. Treat flag count like you treat dependency count—lower is better.

The best feature flag is the one you already removed.

Why Feature Flags Matter#

The Flag Lifecycle#

Types of Flags (They’re Not All the Same)#

Implementation Patterns#

The Naive Approach (Don’t Do This)#

The Better Approach: Strategy Pattern#

Flag Evaluation: Context Matters#

The Cleanup Problem#

Testing with Flags#

Common Pitfalls#

Tooling Options#

The Meta-Rule#

📬 Get the Newsletter