Feature Flag Config Builder

Feature flags and feature toggles are the same concept — they are runtime switches that let you enable or disable functionality without deploying new code. 'Feature flag' is the term popularized by tools like LaunchDarkly, while 'feature toggle' was coined by Martin Fowler. Both refer to conditional logic (if flag enabled: show new UI) that decouples deployment from release. This lets teams do trunk-based development, canary releases, A/B testing, and instant rollbacks without touching infrastructure.

OpenFeature is a CNCF-incubating open standard for feature flagging. It defines a vendor-neutral SDK API so you can switch between flag providers (LaunchDarkly, GrowthBook, Flagd, Unleash) without changing your application code. You write against the OpenFeature SDK, plug in your provider of choice, and the SDK handles evaluation. The JSON provider format generated by this tool works with @openfeature/flagd-provider, letting you serve flags from a flat JSON file — perfect for local development, CI environments, or self-hosted setups.

Percentage rollout assigns users to the 'on' or 'off' bucket based on a hash of their user ID (or session ID). Because the hash is deterministic, the same user always gets the same bucket — this is called stickiness. A 20% rollout means roughly 20% of unique users consistently see the feature enabled. LaunchDarkly and GrowthBook both use this approach. The OpenFeature JSON provider supports it via the 'fractional' evaluator. Without stickiness (random per request), users would see the feature flicker on and off, which is never desirable.

Feature flags are technical debt by design — they exist to be temporary. A flag should be removed once the rollout is complete (100% on or fully off). Common practice is to treat flags like TODO comments: file a cleanup ticket the moment you create the flag, set a calendar reminder for 30-90 days, and enforce it with static analysis tools (like eslint-plugin-feature-flags) that fail the build if a flag key is older than N days. LaunchDarkly and GrowthBook both have built-in staleness tracking. Flags left in the codebase for months become invisible dead code that confuses future developers.