Feature Flags & Experimentation Platform

A conditional check in code that enables or disables functionality at runtime without deploying new code. Allows dark launches, gradual rollouts, A/B tests, and instant kill switches. The condition is evaluated against a flag key and context.

"The new checkout flow is behind a feature flag. In code: if (ldClient.variation(‘new-checkout’, userContext, false)) { renderNewCheckout() } else { renderOldCheckout() }. We can enable it for internal users, then 5% of production, then 100% — all without a deploy. If something goes wrong, one toggle flip reverts it."

A conditional in the feature flag configuration that serves a specific variation to users who match defined criteria — by user attribute (plan, region, email), group membership (segment), or percentage rollout.

"The feature flag has three targeting rules: 1) users in segment ‘beta-testers’ get variation ‘on’, 2) users with email @company.com get variation ‘on’, 3) everyone else gets a 10% rollout. Rules are evaluated in order — the first match wins. The default variation for unmatched users is ‘off.’"

A feature flag used to instantly disable a feature in production without a deployment. The flag is evaluated at runtime — when the kill switch is flipped, all active instances stop serving the feature within milliseconds.

"We always wrap new infrastructure integrations in a kill switch. When the third-party payment provider had an outage, we flipped the kill switch — the system reverted to the backup provider instantly. No deploy needed, no incident escalation delay. Every risky feature gets a kill switch at launch."

Ensuring a user consistently receives the same variation across multiple flag evaluations, even if the rollout percentage changes. Without sticky bucketing, a user in a 10% rollout might see the feature, then not see it on their next visit if they’re re-evaluated.

"Without sticky bucketing, our 10% rollout users had a confusing experience: the new dashboard appeared on login, disappeared on refresh. We enabled sticky bucketing — variation assignment is hashed on user ID and persisted, so the same user always gets the same variation for the duration of an experiment."

Feature flags classified by lifetime and purpose. Release toggle: short-lived, for safe trunk-based development. Ops toggle: long-lived operational control (kill switch, circuit breaker). Experiment toggle: temporary, for A/B testing. Permission toggle: permanent, for entitlement (feature gating by plan).

"We audited our flags by type: 47 release toggles (oldest 8 months — cleanup needed), 12 ops toggles (circuit breakers, kept), 8 experiment toggles (results done, remove the code), 23 permission toggles (plan-based gating, permanent). Stale release and experiment toggles create technical debt — we scheduled a flag cleanup sprint."

Server-side: flag evaluated in backend code using an SDK; variation decision never exposed in the browser. Client-side: flag variations sent to the browser via a bootstrap payload; evaluated in JavaScript. Trade-off: server-side is more secure; client-side enables faster rendering.

"Premium features are server-side evaluated — if evaluated client-side, a user could inspect the payload and see flag variations for features they don’t have access to. UI variations (button colour, layout) are client-side — the bootstrap payload is delivered with the page, enabling immediate rendering without a flag API roundtrip."

Feature flags that are no longer needed but remain in the codebase — creating dead code paths, increasing cognitive complexity, and risking accidental re-activation. Like technical debt but specific to feature toggles.

"The launch flag for the 2023 redesign is still in the code — it’s been 100% on for 18 months. The flag code adds complexity: every component has if (newDesign) branches. We scheduled a cleanup sprint: remove the flag, keep the new design path, delete the old path entirely. Estimated: removes 2,000 lines of dead code."