English for LaunchDarkly Feature Flags

Feature flags let you decouple deploying code from releasing it, but that only works well as a team practice if everyone uses the same vocabulary for targeting, variations, and rollback — otherwise “turn off the flag” can mean five different things depending on who says it.

Key Vocabulary

Flag variation — one of the possible values a flag can serve (often true/false, but can be a string, number, or JSON object), evaluated per request based on targeting rules. “This isn’t a simple on/off flag — it has three variations controlling which of three checkout layouts a user sees.”

Targeting rule — a condition (based on user attributes like plan tier, region, or a percentage rollout) that determines which variation a specific user or request receives. “We added a targeting rule serving the new variation only to users on the enterprise plan in the EU, so we can validate it with a controlled audience first.”

Percentage rollout — a targeting rule that distributes traffic across variations by percentage rather than by explicit attribute, used to gradually expand exposure to a new feature. “We’re at a 25% rollout right now — if error rates stay flat for another day, we’ll bump it to 50% and keep watching before going to 100%.”

Kill switch — a flag (or a flag’s off-state) used specifically as an emergency mechanism to instantly disable a feature in production without a code deploy or rollback. “We flipped the kill switch the moment the new payment provider started erroring — that took thirty seconds, versus the ten minutes a full rollback would have needed.”

Prerequisite flag — a flag configured to depend on another flag’s state, so its own targeting rules only take effect if the prerequisite flag is also serving a specific variation. “The new dashboard flag has the redesigned nav flag as a prerequisite — it doesn’t make sense to enable one without the other, so we enforced that dependency directly in the flag config.”

Common Phrases

• “How many variations does this flag have, and what determines which one a user gets?”
• “Is this targeting rule based on a user attribute, or a percentage rollout?”
• “What percentage are we at right now, and what’s the plan for ramping up?”
• “Is there a kill switch for this feature if something goes wrong after full rollout?”
• “Does this flag have a prerequisite, or can it be toggled independently?”

Example Sentences

Proposing a rollout plan in a design doc: “We’ll start at a 5% percentage rollout targeting only internal accounts, expand to 25% of all users after 24 hours of clean metrics, then go to 100% — with a kill switch ready at every stage.”

Explaining a targeting decision in review: “This targeting rule only serves the new variation to users with more than ten projects, since that’s the segment most likely to hit the performance issue we’re fixing.”

Responding during an incident: “Flipping the kill switch now — that reverts everyone to the old variation immediately, buys us time to debug without users seeing the broken behavior.”

Professional Tips

• Name the flag variation explicitly when reporting a bug tied to a flag — “the new feature is broken” is far less useful than “variation B of the checkout flag is failing for EU users.”
• State the targeting rule logic plainly when proposing a rollout — “we’ll turn it on for some people” invites confusion; “25% random rollout, no attribute targeting” doesn’t.
• Always confirm a kill switch exists and is tested before a risky flag goes to 100% — discovering there’s no fast way to disable a broken feature mid-incident is a bad time to learn that.
• Track percentage rollout stages and their exit criteria in the rollout plan itself — “we’ll expand it later” without a stated threshold tends to stall indefinitely at whatever percentage feels comfortable.

Practice Exercise

1. Write a sentence explaining the difference between a targeting rule and a percentage rollout.
2. Describe a kill switch scenario and why speed matters there.
3. Explain what a prerequisite flag is in your own words.