What are Feature Flags?

What are feature flags?

Feature flags (also called feature toggles, feature gates, or release toggles) are conditional checks in code that turn application behavior on or off in production without redeploying. The check looks like if (featureFlags.newCheckoutFlow) { /* new code */ } else { /* old code */ }. The value of newCheckoutFlow is fetched at runtime from a flag service — LaunchDarkly, ConfigCat, GrowthBook, or your own homegrown system — and can change instantly for any user, percentage of traffic, or specific cohort.

The core insight: deploy ≠ release. Without flags, shipping code means making it live for everyone. With flags, code can ship to production behind a flag, stay dark for weeks while you tune it internally, then progressively roll out to 1%, 5%, 50%, 100% of users. If something breaks, flip the flag back. No redeploy, no rollback, no panic.

The four canonical use cases

1. Release toggles (gradual rollout)

Ship code to production behind a flag, off by default. Gradually enable it for internal users → beta cohort → 1% canary → 10% → 100%. If metrics degrade at any stage (errors spike, conversion drops, p95 latency rises), flip the flag back instantly. Without flags, you'd need to redeploy or git-revert to recover.

2. Experiment / A/B test toggles

50% of users see version A, 50% see version B. The flag service tracks which user got which variant. Analytics correlate user actions with variant. Statistical analysis decides the winner. Major experimentation platforms (Optimizely, LaunchDarkly Experiments) build entirely on this primitive.

3. Permission / entitlement toggles

Different users see different features based on their plan tier, organization, or role. "Pro plan only" features are flag-gated; the flag's value depends on the user's account state. Functionally similar to traditional authorization but managed in the same flag dashboard as releases.

4. Kill switches (operational toggles)

Wrap risky or expensive code paths (third-party API calls, recommendation engines, ML inference) in flags so you can disable them under load or during incidents. Site is failing because the recommendation API is timing out? Flip the flag, fall back to a simpler experience, deal with the third party in calm.

How feature flag systems work

The architecture under the hood:

• Flag definitions stored centrally. A web dashboard lets product/engineering teams define flags, set targeting rules ("100% of users in EU", "10% of users with plan=pro", "this specific user_id list"), and toggle on/off.
• Client SDKs in your application. Your app fetches flag values from the service either at startup (cached in memory) or per-request (typically with an aggressive local cache). SDKs exist for every major language and framework.
• Streaming updates. Modern flag services use WebSockets or Server-Sent Events to push flag-value changes to running clients within milliseconds. Toggle the flag in the dashboard; production traffic shifts seconds later.
• Telemetry back. Flag services capture which flag values served which requests, enabling auditing ("who flipped this flag at 03:42?") and experimentation (correlating user behavior with variant).

Build vs buy: the four real options

• Buy: LaunchDarkly. The market leader. Mature SDK ecosystem, sophisticated targeting, expensive at scale ($1k-50k+/year). Pay-for-confidence option.
• Buy: ConfigCat / Flagsmith / Statsig. Cheaper alternatives, decent feature sets, faster to evaluate. ConfigCat has a generous free tier; Flagsmith is open-source-and-host-it-yourself friendly.
• Buy: GrowthBook (open source). Particularly strong for experimentation use cases. Self-host or use the SaaS version.
• Build: in-house. A simple flag service is ~500 lines of code: flag definitions in a database, an API to fetch them, a dashboard, basic targeting rules. Worth building if you have specific compliance requirements (data must stay in your VPC) or your team's needs are narrow. Most teams underestimate the long-term maintenance.

Common feature flag pitfalls

• Flag explosion. Without governance, teams ship flags but never delete them. After a year, the codebase has 200 flags, half of which are no longer needed. Set a policy: every flag has an expiration date and an owner; cleanup is part of the release definition of done.
• Hidden coupling between flags. Flag A only makes sense when flag B is on. Without explicit dependencies, a teammate flips B off and breaks A. Keep flag relationships documented; consider a "compound flag" feature in the service.
• Testing matrix explosion. 10 independent boolean flags = 1024 possible code paths. You won't QA all of them. Use prerequisite flags, test the most-used combinations, and rely on production observability to catch the rest.
• Latency on cold cache. First flag fetch on app startup blocks the request. Pre-warm the cache, use streaming SDKs, or fall back to safe defaults if the flag service is unreachable.
• Flag service as single point of failure. If the flag service goes down, your app must keep working. SDKs typically cache the last-known-good values and fall back gracefully — but verify this is true and test it (run a chaos experiment that blocks flag-service network calls).
• Stuck in flag-purgatory. Flag goes from 0% → 50% → stuck. Owner moves teams, flag never reaches 100%. The cleanup half is harder than the rollout half. Build it into your process or you'll drown in cruft.

Feature flags vs config flags vs environment variables

Three related concepts:

• Feature flags: Runtime-mutable, often per-user-targeted, sometimes A/B-tested. Powered by a flag service.
• Config flags: Application configuration (database connection strings, API keys, timeouts). Usually set per-environment, changed via redeploy or config-reload.
• Environment variables: OS-level configuration. Fundamental but inflexible — changes require process restart.

Don't conflate them. Feature flags are for product/release decisions; config is for operational parameters; environment variables are for system bootstrap.

FAQ: Feature Flags

Are feature flags overkill for small teams?

Not anymore. Tools like ConfigCat have free tiers usable for small teams. Even a single dev shop benefits from kill switches and gradual rollouts. The overhead of a flag service is small compared to the firefighting cost of a bad release.

What's the difference between feature flags and trunk-based development?

They're complementary. Trunk-based development means every commit goes to main; feature flags let you safely keep incomplete code in main without users seeing it. Together they enable continuous integration without long-lived branches.

How do feature flags affect testing?

Test the flag-on path AND the flag-off path. CI matrix builds with both states. For multi-flag systems, prioritize the combinations actually used in production. Some flag services (LaunchDarkly, Statsig) integrate with test runners to inject specific flag states for testing.

Can feature flags hurt performance?

If implemented badly, yes — fetching a flag value on every request without caching adds latency. Modern SDKs cache aggressively (in-memory) and update via streaming, so the per-request cost is microseconds, not milliseconds. Audit your SDK setup if flag latency seems high.

Should I use feature flags for permissions?

Mixed opinion. Pros: same dashboard for releases + entitlements. Cons: flag services aren't typically built for fine-grained ACL with audit trails. For complex permission models, use a dedicated authz service (Permit.io, OpenFGA, AWS Cedar). For simple plan-tier gating, flags are fine.

How do feature flags interact with analytics?

Best practice: send the active flag state (or experiment variant) as an event property to your analytics tool. This lets you slice metrics by variant and confirm experiments are statistically valid. Without this, you can't tell if a metric drop is due to a flag change or organic noise.

How LoadFocus relates to feature flag rollouts

Feature flag rollouts are exactly when load testing matters most. New code paths flipped on for 10% of traffic might suddenly hammer expensive endpoints differently than the old code. LoadFocus load testing against the new code path before flag flip validates it holds at scale. API monitoring during the rollout catches latency regressions in real time so you can flip back before users notice.