Feature Flags

Flags decouple deploy from release—and become debt if never removed. Taxonomy, ownership, and retirement matter as much as targeting.

When to Offer This Workflow

Trigger conditions:

• Gradual rollouts, kill switches, or experiments behind flags
• Flag sprawl and unknown defaults
• Client vs server evaluation and hydration flicker

Initial offer:

Use six stages: (1) taxonomy, (2) targeting rules, (3) evaluation & consistency, (4) safety & ops, (5) lifecycle & cleanup, (6) governance). Confirm provider (LaunchDarkly, Unleash, ConfigCat, homegrown).

Stage 1: Taxonomy

Goal: Separate short-lived release flags, long-lived config flags, and experiment flags tied to analytics.

Exit condition: Naming convention and expected TTL per type.

Stage 2: Targeting Rules

Goal: Percentage rollouts, segments (tenant, plan, region), deterministic bucketing (stable user key).

Stage 3: Evaluation & Consistency

Goal: Server-side authoritative for security and billing; client flags for UX only; avoid UI flicker on hydration (SSR/CSR agreement).

Stage 4: Safety & Ops

Goal: Kill-switch runbook; audit trail for changes; safe defaults when provider unavailable (often “off”).

Stage 5: Lifecycle & Cleanup

Goal: Tickets to remove flags after full rollout; periodic audits; metric for stale flags.

Stage 6: Governance

Goal: Approvals for broadening exposure; promotion across environments; break-glass access for incidents.

Final Review Checklist

• [ ] Flag types and naming documented
• [ ] Targeting and bucketing deterministic
• [ ] Server vs client boundaries clear
• [ ] Kill switches and defaults documented
• [ ] Cleanup process and ownership

Tips for Effective Guidance

• Never put security-only gates solely in client-side flags.
• Pair with ab-testing when experiment analysis is primary.

Handling Deviations

• Align with release-management for communication cadence.