Feature flags arrived with a simple promise: ship code without shipping risk. Toggle a boolean, release to ten percent of users, watch for smoke, flip to one hundred. The mechanism is so straightforward that a team can build it in an afternoon. Yet the category has produced a graveyard of vendors who pitched the wrong problem. The ones that survived understood something the market took years to articulate: most feature flag usage is not experimental. It is operational.
The four real jobs of a feature flag
A feature flag serves four distinct operational jobs. Deploy gating, the ability to ship code that is not yet active. The kill switch, a handbrake that turns off a bad release without a rollback. Gradual rollout, the controlled ramp from zero to full traffic. And A/B testing, the experimental use case where different users see different versions of a feature.
As the Hacker News commenter echelon argued in a thread on the topic, runtime-evaluated flags can always serve as control plane levers and emergency handbrakes. The key is distinguishing between ephemeral rollout flags, to be cleaned up or expired, and permanent control plane levers, using the same functionality with different practices. This distinction matters because the jobs are not equally common. Most teams reach for a flag to de-risk a deploy, not to run an experiment. The kill switch and the gradual rollout are the workhorses. A/B testing, while prominent in vendor marketing, is the least common use case in practice.
Flagsmith, in its blog post on Java feature flags, lists phased rollouts, gradual feature rollouts, A/B testing, segmentation, behavior experiments, and feature versioning as use cases. That is a honest catalog of what the mechanism can do. But the order matters. Phased rollouts and gradual rollouts come first because they match how teams actually ship.
Why the A/B framing oversold the category
LaunchDarkly built the category. It also, in a sense, misread it. The company’s early positioning around experimentation created a mismatch with actual usage patterns. As the Hacker News commenter chambers observed in the same thread, experimentation platforms like Statsig built their system on the distinction between feature flags and dynamic configs, partly enabling a billion-dollar sale. Companies like LaunchDarkly that ignored the difference struggled outside of feature flags.
The market rewarded operational clarity over experimental ambition. Flagsmith, positioning itself as an open-source, all-in-one platform for developing, implementing, and managing feature flags, with seamless integration across multiple programming languages and a simple UI, gained traction by emphasizing the operational core. GrowthBook followed a similar path, building for the team that needs to ship safely first and run experiments second.
The pattern is clear. Vendors who pitched A/B testing as the primary value proposition found themselves competing against in-house solutions and analytics platforms. Vendors who pitched operational control, the ability to ship faster with less risk, found a market that was already living that reality.
The kill switch and the gradual rollout are the workhorses. A/B testing, while prominent in vendor marketing, is the least common use case in practice.
The hidden cost of permanent flags
The operational value of feature flags comes with a structural cost. Flags left in code create combinatorial test explosions and incident risk. A Hacker News commenter, ZephyrBlu, reported that at Shopify, feature flags were mandated to have a short lifetime, two to four weeks tops, with some exceptions, because they would end up left in code and never cleaned up. Feature flag flips in production were a major source of incidents.
The combinatorial problem compounds. Another commenter, jeremyjh, noted in the same thread that when multiple feature flags can interact, the number of test cases explodes. Three interacting flags in a module with one hundred test cases would require nine hundred test cases to cover all combinations. That is not a theoretical risk. It is a concrete drag on every team that lets flag debt accumulate.
The tension is real. The same mechanism that enables safe deploys also enables sloppy practices. The solution is not to ban permanent flags. It is to distinguish between ephemeral rollout flags and permanent control plane levers, as echelon argued, and to enforce that distinction through practice, not just policy. A kill switch that lives in the codebase for years is not technical debt. It is infrastructure. A rollout flag that lives in the codebase for months is technical debt, and it will eventually cause an incident.
The case for OpenFeature and vendor neutrality
If flags are primarily operational levers, they should be portable across providers. The mechanism should not be a proprietary platform bet. It should be a commodity infrastructure layer.
OpenFeature, the CNCF project that provides a vendor-neutral flag evaluation standard, addresses exactly this need. By abstracting the flag evaluation API from the backend provider, it allows teams to treat flags as a durable investment rather than a vendor dependency. The standard reduces lock-in and makes the flag system something a team can build around with confidence, knowing that switching providers does not require rewriting the integration layer.
The operational-first thesis makes this standard more than a nice-to-have. If flags were primarily experimental, the vendor lock-in might be acceptable, because the experiment platform is the product. But if flags are primarily operational, a standard that outlasts any provider is the correct architecture. The flag system should be as portable as the logging system or the metrics pipeline.
A minimum-viable flag system you can build in an afternoon
The operational core of feature flags is so simple that a team can build it in an afternoon. A JSON config file, a kill switch that reads a boolean, and a gradual rollout percentage that samples traffic. That covers eighty percent of real-world use cases.
The decision to buy a vendor like Flagsmith or GrowthBook hinges on whether you need the surrounding infrastructure. Multi-environment segmentation, so that staging and production do not share the same flag state. Audit trails, so that every flag flip is logged and attributable. Experimentation analytics, so that A/B tests produce statistically sound results without building the pipeline yourself.
Flagsmith, as its blog post on Java feature flags describes, makes toggling a flag as simple as clicking a UI button, making releases more efficient and lower risk. That UI button is the value. The underlying mechanism is trivial. The discipline of managing flags at scale, with visibility and accountability, is not.
The A/B framing was always overkill for most teams. The operational framing is not. It matches how teams actually ship, what they actually need, and the discipline they actually struggle to maintain. The vendors that survived understood this. The ones that did not are the ones that pitched experiments first and operations second.
The market has spoken. Feature flags are infrastructure, not a science project. Treat them accordingly.