Feature Flags & A/B Testing

Concept#

Decoupling Deployment from Release#

• Deployment: The physical execution of copying code bundles to production servers.
• Release: The business decision to make a feature visible to users.

Feature Flags (toggles) let you push unfinished or dark features to production behind a conditional check:

const isNewCheckoutEnabled = useFeatureFlag('checkout_redesign');
 
return isNewCheckoutEnabled ? <NewCheckout /> : <OldCheckout />;

This enables trunk-based development, where developers merge code directly into the main branch multiple times a day, avoiding long-lived feature branches and painful merges.

Canary Releases & A/B Testing#

Feature flags support dynamic evaluation based on user context:

1. Targeting Rules: Turn a feature on for internal QA users first, then for 1% of public users, and scale up (canary rollout).
2. A/B Testing: Assign users randomly to variants (e.g. Variant A vs Variant B). Track conversion metrics for each group to make data-driven decisions.

  ┌────────────────────────────────────────────────────────┐
  │                   Feature Flag Server                  │
  │                  (Targeting/Allocation)                │
  └──────────┬──────────────────────────────┬──────────────┘
             ▼ 10% Variant A                ▼ 90% Control
     ┌───────────────┐              ┌───────────────┐
     │ New Blue CTA  │              │ Old Red CTA   │
     │  Button view  │              │  Button view  │
     └───────────────┘              └───────────────┘

Common Mistakes#

1. Cumulative Technical Debt (Dead Flags)#

Once a feature is fully released, developers forget to clean up the code checks. Over time, codebases accumulate hundreds of nested feature flags, making logic hard to trace. Establish strict lifecycle tracking to remove flag code within weeks of complete rollout.

2. Network Latency Blocking Initial Renders (Flicker)#

Evaluating flags via network requests on startup can cause a layout shift or flash of old content while waiting for the response. Solve this by bootstrapping default flag states in SSR payloads or edge caches.

Best Practices#

• Set Default Fallbacks: Always provide static default values in client code in case the feature flag server goes offline.
• Use Edge Middleware: Evaluate flags at the edge CDN layer (e.g., Vercel / Cloudflare workers) to rewrite HTML payloads instantly without browser-side layout shifts.
• Group Flags by Purpose: Distinguish short-term release flags (canary rollouts) from long-term ops toggles (kill switches) or permissions.