Feature flags are an architecture discipline, not a marketing checkbox

Every vendor selling a flagging tool shows the same demo: flip a toggle, feature appears, flip it back, feature disappears. That demo is true and almost useless. The hard part of progressive delivery isn't the toggle. It's everything the toggle is load-bearing for once it's live in front of real traffic: what percentage gets it, how fast that percentage grows, what happens when the flag needs to come off under pressure, and who's responsible for deleting it six months later. Get those wrong and you've built a second, undocumented deployment system that nobody trusts.

Canary percentages are a sampling problem, not a slider

Teams set canary rollouts to "5%, then 25%, then 100%" and treat the numbers as arbitrary courage levels. They're not. Five percent of your traffic needs to contain enough of the segments that break things: your largest enterprise tenant, your oldest browser cohort. If your flagging system buckets by random hash without weighting for tenant size or usage pattern, "5%" can mean zero percent of the traffic that actually exercises the failure mode you're worried about. We've seen a canary sit at 10% for four days, look clean, then blow up at 40% because the bug only triggered on accounts with more than 200 concurrent sessions, a shape that didn't exist below quarter-scale exposure.

The fix isn't a bigger canary. It's canary criteria tied to what you're actually testing: percentage of a specific tenant tier, or percentage of a specific write path, not a flat slice of "users." And the ramp schedule needs an automatic hold, not a human watching a dashboard at 6pm on a Friday. If your flagging platform can't gate the next percentage bump on an error-rate or latency SLO automatically, you don't have progressive delivery. You have a manual rollout with extra steps.

A kill switch you haven't drilled is a hope, not a control

Kill switches get built once, tested once in staging, and then never touched again until the night you need them, at which point nobody remembers the flag key, the on-call engineer doesn't have permission to flip it, flipping it turns out to cascade into a cache invalidation storm nobody modeled, or the switch was wired to a stale config path that got refactored away two sprints ago. A kill switch is an incident-response primitive. It belongs in the same category as your runbooks: it needs an owner and a drill on the calendar, not just a code path.

The concrete test: can an on-call engineer with no prior context on this feature find the flag, understand what turning it off actually disables, and execute the change in under two minutes at 3am? If the answer involves paging the original author, the kill switch doesn't exist yet, whatever the code says.

Flag debt is technical debt with worse tooling

A flag that's been at 100% for eight months and never removed isn't neutral. It's a live conditional multiplying your test matrix, a dependency the next migration has to route around, and a landmine for whoever refactors that module without knowing the "temporary" branch is actually load-bearing for a customer contract signed in Q1. Flag debt is worse than ordinary debt because it's invisible in the codebase's structure: if (flag.enabled) reads the same whether the flag rolled out yesterday or three years ago.

Treat flags as owning a lifecycle, not just a state. Every flag gets an expiry date at creation and a linked ticket to remove it once it's fully rolled out or fully killed. Enterprises running six-figure flag counts almost always got there by skipping this step, not by having six figures' worth of legitimate ongoing experiments. In client engagements we've pulled teams out of exactly this hole by auditing flag age against rollout percentage and deleting anything past 100% for more than one release cycle.

None of this is about picking LaunchDarkly over Unleash or building your own. It's about deciding, before the first flag ships, who owns the ramp curve and who's accountable for the flag's death. Skip that design work and the flagging system becomes exactly what it looks like in the vendor demo: a toggle, with none of the discipline that makes it safe to pull.