Feature Flag
An engineering practice that decouples code deployment from feature release. A flag controls whether a new feature is visible to users, supporting gradual rollout and rapid rollback.
Timeline (last 90 days)
A feature flag is an engineering practice that decouples feature release from code deployment: switch checks are embedded in the code in advance, and the configuration center dynamically determines which users and which environments a feature takes effect for.
Feature flags and A/B testing share the "grouping + traffic splitting" capability in engineering implementation, but their goals differ: flags focus on release control, while experiments focus on causal inference.
Using feature flags' percentage rollout directly to run experiments makes it easy to encounter problems such as non-random traffic splitting, imbalanced sample proportions, and the same user being assigned to different groups on different devices.
The value of Flagsmith Experiments lies in reusing the existing grouping identifiers of flags as experiment units and supplementing them with a randomization and statistics layer.
Feature flag platforms typically bill by "context", i.e. each evaluated user or device identifier counts as one metering unit. Because anonymous visitors have no stable ID, platforms often generate a new context for each session or even each page load, causing MAU counts to be inflated.
Local Evaluation mode uses a server-side SDK to periodically pull the full rule set and evaluate it in memory, communicating with the platform only when rules change, thereby shifting the billing unit from "per evaluation" to "per rule sync".
On LaunchDarkly, anonymous visitors push up client-side monthly active context costs, reaching about $1,020/month at 100k MAU.
All Facts (7)
A feature flag is an engineering practice that decouples feature release from code deployment: switch checks are embedded in the code in advance, and the configuration center dynamically determines which users and which environments a feature takes effect for.
50%UnverifiedFeature flags and A/B testing share the "grouping + traffic splitting" capability in engineering implementation, but their goals differ: flags focus on release control, while experiments focus on causal inference.
50%UnverifiedUsing feature flags' percentage rollout directly to run experiments makes it easy to encounter problems such as non-random traffic splitting, imbalanced sample proportions, and the same user being assigned to different groups on different devices.
50%UnverifiedThe value of Flagsmith Experiments lies in reusing the existing grouping identifiers of flags as experiment units and supplementing them with a randomization and statistics layer.
50%UnverifiedFeature flag platforms typically bill by "context", i.e. each evaluated user or device identifier counts as one metering unit. Because anonymous visitors have no stable ID, platforms often generate a new context for each session or even each page load, causing MAU counts to be inflated.
50%UnverifiedLocal Evaluation mode uses a server-side SDK to periodically pull the full rule set and evaluate it in memory, communicating with the platform only when rules change, thereby shifting the billing unit from "per evaluation" to "per rule sync".
50%UnverifiedOn LaunchDarkly, anonymous visitors push up client-side monthly active context costs, reaching about $1,020/month at 100k MAU.
50%