Server-Side Experiment Assignment Built Into Your Stack

When this is worth building: Server-side assignment earns its cost when the thing being tested cannot be repainted in a browser: a price, a rate limit, a matchmaking rule, a ranking function, an onboarding sequence, the body of an API response. If your tests change headlines and images, this is an expensive way to do something a client-side tool already does well, and I will tell you that on the first call. The build described here typically runs six to ten weeks with two of your engineers part-time, and what it produces is assignment your data team trusts without a reconciliation step before every readout. How assignment is done: Deterministic hashing of a stable unit id with a per-experiment salt, bucketed into 10,000 slots. The same user gets the same variant from any service, in any language, in any region, with no lookup and no coordination. This matters more than it sounds: it is what lets a Go backend, a Unity client and a marketing site agree without a round trip. Where latency is the constraint, evaluation moves to the edge, in Next.js middleware, Cloudflare Workers with the payload in KV, or Fastly Compute, with a stale-while-revalidate window you choose rather than inherit from a default. Exposure logging: Assignment is half the job. Exposure events travel the path your other events already take, through Kafka, Kinesis, Segment or direct batch, deduplicated on unit and experiment, stamped with the variant and the config version. Config version is the detail teams skip: without it, a mid-flight flag edit is invisible in the analysis and a contaminated test reads as a clean one. Structure that stops tests eating each other: Mutual exclusion layers where tests touch the same surface. A standing holdout, usually five percent and sometimes one percent at scale, that sees no experiment at all, which is the only honest way to answer what a year of shipping was worth. Kill switch semantics that are tested rather than assumed: during the build an engineer proves in production that a flag turns off, because the one time it matters is a Saturday. Flag hygiene: Flags are debt and this build includes the repayment schedule. A cap on live experiment flags, a named owner on each, and a job that opens a ticket when a flag has sat at 100 percent for 30 days. Programmes that skip this reach a point in year two where nobody can state what the control experience is. SDKs and surfaces: GrowthBook and Statsig across Node, Go, Python, Kotlin, Swift and Unity, or OpenFeature where you want the provider swappable later. For games this includes LiveOps configuration treated as an experiment surface rather than a parallel system, with the client cache problem handled honestly: a player who has not reopened the app has not been exposed, and counting them as exposed is how a live-ops team talks itself into a result. Not included: I will not build you an in-house experimentation platform. Done properly that is three engineers for a year, it is the wrong trade for nearly every company that asks, and the honest version of that conversation is short. No warehouse migration and no event pipeline rebuild; if your events are unreliable that gets fixed first, by your team. No statistical engine either, since this build produces trustworthy assignment and exposure data and the analysis is separate work. Who this is not for: Teams without a functioning warehouse, and teams who want flags purely for release management. The second is a real need, and cheaper engineers do it well.