Feature flags must toggle independently per user

What it is

If a canary can only cut by build or by server, a given user, device class, or organization cannot be pulled into or out of the trial on its own. A feature flag (feature toggle) has to land on-off on a user dimension (and the account, device, or tenant bound to that user), and flags must be independent: turning on interaction A must not drag on interaction B; stopping one person must not stop a whole machine. Humble and Fowler discussed feature toggles first as engineering decoupling; for evaluation they are the operable experimental unit. Without per-user independent toggling, rollback and stratified sampling cannot be fine.

Why it happens

Interaction evaluation needs contrast at the person layer: on the same day some people see the new flow and some do not; a complainant must be switchable off without punishing others in the same rack. If the flag is bound to a build or a data center, on-off becomes an infrastructure event, experience problems cannot be isolated, and a pilot organization cannot be separated from its neighbor. Independence also prevents a big-bang flag: a bundle of untested interactions rides one bit, everything opens at once, and failure cannot be attributed. Addressing per user wants stable identity—anonymous use, multiple devices, and shared accounts bounce the same person in and out and contaminate stage stats. The flag itself must be fast: if off requires a new ship, the checkpoint is only nominal.

Studying it

Treat the flag matrix as part of the method description: dimensions (user, org, device), default, change latency, who may flip. Audit a real rollback: how long from the call to the target user losing the new path, and who was collateral. Comparative work can contrast “percentage-random only” with “stratified named users” on how problems get localized. Logs must record operator and scope of every flag change, or stage data cannot be interpreted. Evaluation plans should forbid undocumented hot flags.

Where it stops holding

Products without stable identity (one-shot sessions, public terminals) cannot truly toggle per user; session or device is an approximation and must be said. On enterprise products a tenant flag may fit better than a person flag, but within-tenant person differences get flattened. Features that compliance requires to switch for everyone at once (tax, contract terms) cannot canary per user. Flag explosion becomes configuration debt; independence needs governance, not infinite bits. Client caches can leave “already off, still visible,” so independent toggling holds in the protocol and lags in the experience.

Applying it

• One flag per interaction under evaluation, default off, addressed by user or tenant—not by build number.
• The on-call manual must say how to turn off one user and a whole stratum in minutes, and that path must be drilled.
• Write changes to an audit log and attach the timeline to the evaluation report.
• If you cannot stop per user, take the feature off the canary list and run a stoppable pilot, rather than pretending a flag exists.

Related

• Same group: Q5.09.1 Rollout share usually increases by stage, each with a continue-or-pause gate · Q5.09.3 Pilot users must know they are in a trial so they can interpret failures · Q5.09.4 Monitoring during rollout must cover exceptions and performance, not only business metrics
• Adjacent: Q5.06 Canary release and pilots · Q3.04 A/B testing
• Search terms: per-user feature flags · feature toggle · kill switch granularity