A feature toggle system is a rules engine: given a flag's conditions and a context, decide on or off — wrapped in an ergonomic API.

The flag model

A flag isn't just a boolean — it has rules:

{
  key: "new-checkout",
  enabled: true,                          // master switch
  rules: [
    { type: "user",        userIds: ["u1", "u2"] },     // explicit targeting
    { type: "role",        roles: ["beta-tester"] },
    { type: "percentage",  rollout: 25 },               // gradual rollout
    { type: "environment", envs: ["staging"] },
    { type: "dateWindow",  start: "...", end: "..." },
  ],
}

The evaluator

A pure function: (flag, context) => boolean, where context is { userId, role, env, ... }.

function evaluate(flag, context) {
  if (!flag.enabled) return false;
  // a flag is ON if the context matches its rules (any/all per design)
  return flag.rules.some((rule) => matchesRule(rule, context));
}

• Percentage rollout must be stable per user — hash userId + flagKey to a number 0–99 and compare to rollout. Same user always gets the same answer; otherwise the UI flickers on every load.
• Decide any vs all rule semantics (OR vs AND), or support both.

The React API

<FeatureFlagProvider flags={flags} context={{ userId, role, env }}>
  ...
</FeatureFlagProvider>

function Checkout() {
  const isNew = useFlag("new-checkout");
  return isNew ? <NewCheckout /> : <OldCheckout />;
}

A provider holds the flags + context and the evaluated results; useFlag(key) reads the evaluated value.

Production concerns

• Remote config — flags fetched from a service (LaunchDarkly, or your own), so you flip features without a deploy. Refresh/poll or stream updates.
• Caching & performance — evaluate once per flag per context, memoize; don't re-evaluate every render.
• Safe defaults — if the flag service is unreachable or a flag is unknown, fall back to a safe default (usually "off") — never crash because flags failed to load.
• SSR consistency — evaluate the same way on server and client to avoid hydration mismatch.
• Cleanup discipline — flags are tech debt; track and remove stale ones.
• Analytics/exposure logging — record which users saw which variant (for A/B analysis).
• Kill switch — every risky flag can be turned off instantly.

The framing

"It's a rules engine. A flag has a master switch plus rules — explicit user/role targeting, percentage rollout, environment, date windows. A pure evaluator (flag, context) => boolean checks the context against the rules; the key subtlety is percentage rollout must hash userId + flagKey so it's stable per user, not random per load. I'd expose it as a provider holding flags and context, with a useFlag(key) hook reading memoized evaluations. Production-wise: remote config so I can flip flags without a deploy, safe 'off' defaults if the service is down, SSR-consistent evaluation, exposure logging for A/B, and discipline around removing stale flags."