Dev Feature Flag Implementation Guide

Create a feature flag implementation guide for [application].

Application details:
- Application: [name]
- Language: [language]
- Scale: [users]
- Use cases: [gradual rollout/A/B testing/kill switch]
- Tool: [LaunchDarkly/Unleash/custom/environment variables]

FEATURE FLAG GUIDE

1. WHAT ARE FEATURE FLAGS?
   Conditional code execution controlled by configuration
   not code deployment.

   USE CASES
   - Gradual rollout: [release to 5% → 25% → 100%]
   - A/B testing: [test different versions]
   - Kill switch: [disable feature without deploy]
   - Beta testing: [specific user groups]
   - Operational: [maintenance mode]

2. IMPLEMENTATION PATTERNS

   SIMPLE BOOLEAN FLAG
   ```javascript
   const NEW_CHECKOUT = process.env.FEATURE_NEW_CHECKOUT === 'true'

   if (NEW_CHECKOUT) {
     return newCheckoutFlow()
   } else {
     return legacyCheckoutFlow()
   }
   ```

   USER TARGETING
   ```javascript
   function isFeatureEnabled(featureKey, userId) {
     const flag = featureFlags.get(featureKey)
     if (!flag.enabled) return false

     // Percentage rollout
     const userHash = hashUserId(userId)
     return userHash % 100 < flag.rolloutPercentage
   }
   ```

3. FLAG NAMING CONVENTIONS
   - Format: [FEATURE_AREA_DESCRIPTION]
   - Examples:
     * FEATURE_CHECKOUT_NEW_FLOW
     * FEATURE_DASHBOARD_DARK_MODE
     * KILL_SWITCH_EMAIL_SENDING
   - Boolean: [enabled/disabled]
   - Avoid: vague names like FEATURE_NEW

4. FLAG LIFECYCLE

   CREATION
   - Document purpose: [why this flag exists]
   - Owner: [team/person]
   - Target removal date: [after full rollout]

   ROLLOUT STAGES
   - 0% — Flag created — not released
   - 5% — Internal employees
   - 25% — Beta users
   - 50% — Half of users
   - 100% — Full rollout
   - Remove flag — Clean up code

   REMOVAL (critical — avoid flag debt)
   - Remove flag after 100% rollout + stable
   - Remove non-winning A/B test variant
   - Set reminder: [calendar event]

5. TESTING WITH FLAGS
   ```javascript
   // Test both paths
   describe('checkout with feature flag', () => {
     it('uses new flow when flag enabled', () => {
       mockFlag('FEATURE_NEW_CHECKOUT', true)
       // test
     })
     it('uses old flow when flag disabled', () => {
       mockFlag('FEATURE_NEW_CHECKOUT', false)
       // test
     })
   })
   ```

6. ANTI-PATTERNS TO AVOID
   - Nested flags: [hard to reason about]
   - Flags that live forever: [technical debt]
   - Flags without owners: [orphaned]
   - Flags in database queries: [performance]
   - Too many flags active at once: [complexity]