Feature flag system configured

Severity: Recommended

Feature flags decouple deployments from releases, enabling gradual rollouts, A/B testing, and quick rollbacks. Small projects can use environment variables; larger projects need a dedicated service like GrowthBook.

Check automatically:

1. Check for feature flag libraries:

# GrowthBook (recommended)
grep -E "\"@growthbook/growthbook\"|\"@growthbook/growthbook-react\"" package.json 2>/dev/null

# Other feature flag services
grep -E "\"launchdarkly|\"unleash-client\"|\"flagsmith\"|\"@openfeature\"" package.json 2>/dev/null

# Posthog (includes feature flags)
grep -E "\"posthog-js\"|\"posthog-node\"" package.json 2>/dev/null

2. Check for feature flag configuration:

# GrowthBook configuration
grep -rE "GrowthBook|growthbook" src/ app/ lib/ --include="*.ts" --include="*.js" 2>/dev/null

# Feature flag environment variables
grep -rE "GROWTHBOOK|LAUNCHDARKLY|UNLEASH|FLAGSMITH" .env* 2>/dev/null
env | grep -iE "growthbook|feature" 2>/dev/null

3. Check for feature flag usage in code:

# Common feature flag patterns
grep -rE "isOn\(|isFeatureEnabled|useFeature|useFeatureFlag|getFeatureValue|feature\." src/ app/ lib/ --include="*.ts" --include="*.js" 2>/dev/null

# GrowthBook specific
grep -rE "\.isOn\(|\.evalFeature\(|useFeatureIsOn|useFeatureValue" src/ app/ lib/ --include="*.ts" --include="*.js" 2>/dev/null

# Simple env var flags (acceptable for small projects)
grep -rE "FEATURE_|ENABLE_|FF_" src/ app/ lib/ --include="*.ts" --include="*.js" 2>/dev/null
grep -rE "process\.env\.FEATURE_|process\.env\.ENABLE_" src/ app/ lib/ --include="*.ts" --include="*.js" 2>/dev/null

4. Check for feature flag configuration files:

# GrowthBook features JSON
find . -name "features.json" -o -name "growthbook*.json" 2>/dev/null

# Feature flag configs
find . -name "*feature*flag*" -o -name "*flags*" 2>/dev/null | grep -v node_modules

5. Check capabilities (if using a feature flag service):

For GrowthBook or similar services, verify these capabilities exist:

• A/B testing: Can assign users to variants and measure outcomes
• Percentage rollouts: Can roll out to X% of users
• Sticky assignment: Same user gets same variant consistently (user ID hashing)
• User segment targeting: Can target by user attributes (plan, role, region, etc.)

# Check for experiment/variant usage (A/B testing)
grep -rE "experiment|variant|useExperiment|runExperiment" src/ app/ lib/ --include="*.ts" --include="*.js" 2>/dev/null

# Check for targeting attributes being set
grep -rE "setAttributes|setAttribute|attributes:" src/ app/ lib/ --include="*.ts" --include="*.js" 2>/dev/null

# Check for percentage/weight configurations
grep -rE "coverage|weight|percentage|rollout" src/ app/ lib/ --include="*.ts" --include="*.js" 2>/dev/null

Ask user:

• "What's the project scale? (Small = env vars OK, Large = need GrowthBook)"
• "Are feature flags actively used, or just installed?"
• "Do you need A/B testing capabilities?"
• "Do you need to target features by user attributes (plan type, region, etc.)?"

Cross-reference with:

• FF-002 (kill switches use the same infrastructure)
• DEPLOY-001 (deployments should be decoupled from releases)
• Section 35 (incident response - kill switches in playbooks)

Pass criteria:

• Feature flag system exists (env vars for small projects, dedicated service for larger)
• Flags are actually used in production code (not just installed)
• Clear pattern for adding new flags
• For dedicated services: percentage rollouts, sticky assignment, and segment targeting supported

Fail criteria:

• No feature flag system
• Library installed but never used in code
• Only hardcoded boolean toggles with no external control
• Large project using only env var flags (need proper service)

Evidence to capture:

• Feature flag system in use (GrowthBook, env vars, etc.)
• Count of active flags in codebase
• Capabilities available (A/B testing, percentage rollouts, targeting)
• Whether flags are actually being used (not just configured)

---