Client-Side Feature Flag and Experimentation SDK

Model response

For most companies buying is straightforwardly correct and I would recommend it — the SDK is the easy part and the analysis pipeline, the admin UI, and the SDK matrix across every language are where the years go. The cases where building wins are specific and worth naming: per-seat or per-MAU pricing that becomes untenable at very high traffic, data residency requirements that a vendor cannot satisfy, or a need to join exposures against an internal metrics warehouse that no vendor can reach. A reasonable middle path, which is what I would actually propose first, is to buy the platform and write a thin internal wrapper around the vendor SDK — that gives us consistent conventions, an abstraction seam if we ever migrate, and the ability to add company-specific guardrails without owning the hard parts. I would only build the whole thing when a concrete cost or compliance number justifies the ongoing headcount, and I would want that number written down.

Model response

That is entirely accurate and it is the real cost of local evaluation — flag keys, segment definitions, and rollout percentages are all visible, and for an unannounced product this is a genuine problem rather than a theoretical one. Mitigations are partial, and I want to be honest about that. Rules that depend on sensitive attributes can be evaluated server-side with only the resolved value sent down; flags for unannounced work can be scoped so they are not included in the ruleset for users outside the target segment; and keys can be opaque, though that is obfuscation rather than security. What I would not do is claim local evaluation is safe for genuinely confidential launches. For those, server-side evaluation is the right answer and the latency cost is acceptable because they are rare. The general case gets local evaluation because a synchronous, offline-resilient flag read is worth far more across thousands of daily evaluations than secrecy is on the handful that need it.

Model response

You are right that they conflict, and the resolution is that they are two different kinds of flag rather than one behavior. Experiment flags freeze for the session, because a variant changing mid-session both ruins the user's experience and makes the data uninterpretable — that user is now in neither arm. Operational kill switches propagate immediately, because the entire point is to stop harm and a user losing a broken feature mid-session is the desired outcome, not a regression. So the flag type is declared at creation and the SDK honors different update semantics per type. The place this genuinely stays hard is a flag that is both, which is common: an experiment that also needs an emergency off switch. My answer there is that the kill switch is a separate flag gating the experiment, so the emergency path is explicit and the experiment flag stays frozen. That costs an extra flag per risky experiment, which I think is a fair price for not having to reason about it during an incident.

Model response

That framing is correct and I would hold the budget tightly rather than treat 15KB as a floor. Concretely: the evaluation core is a few kilobytes, and the bulk of any bloat comes from the ruleset payload and optional features, both of which are addressable. Scope the ruleset per surface so a marketing page carries five flags rather than three thousand. Tree-shake flag types the product does not use. Make the exposure pipeline and the devtools panel lazy, since neither is needed for the first evaluation. Where I would resist is removing the SSR bootstrap to save bytes — that few hundred bytes is what prevents a layout-shifting flicker, and CLS is a worse performance outcome than the payload. I would also put the SDK's own bundle size in CI with a hard budget, because a platform library that grows unnoticed imposes its cost on every team and none of them can see it.