SDLC, DevOps & Developer Experience · Chapter 14 of 15
Progressive delivery and feature flags, in the market
Two controllers you choose by your GitOps engine, a pricing model that just inverted, and what the flag standard does and does not give you.
Chapter one covered the deployment strategies. This one is the products — and there is one genuinely significant pricing change that makes older comparisons the wrong shape.
The two progressive-delivery controllers
Both are mature, free, open source, and actively maintained — they shipped releases three days apart in mid-2026, so neither is winning by the other's abandonment. The difference is architectural:
| Controller A | Controller B | |
|---|---|---|
| How it works | Replaces your deployment object with its own resource type | Sits on top of your existing deployment as an operator |
| You write | Canary steps explicitly and in order, with analysis at chosen points | A declarative analysis specification; it progresses automatically |
| Traffic shifting | Built in, with its own dashboard | Driven by a service mesh or ingress controller |
| Trade | More control, more to write | Less control, less to write |
Choose by your GitOps engine, not by the feature list
Each controller is the sibling project of one of the two dominant GitOps engines, and the integration is the point.
If you run one engine, use its sibling — because the rollout state then appears in the same interface as your sync state, and seeing the rollout is most of what makes progressive delivery worth doing.
Choosing across the grain costs you exactly the observability that justified the investment. This is a case where the integration matters more than the capability, and candidates who lead with a feature comparison have usually not operated either.
Feature-flag vendors, and the repricing that changes the answer
The market leader removed its per-seat fee entirely.
It was the archetypal per-seat feature-flag vendor and was widely described as expensive on that basis. Its current mid-tier has no platform fee and no seat fee at all — the meter is monthly active users plus service connections.
That inverts which companies find it expensive. The cost driver moved from ‘how many engineers do you have’ to ‘how many end users do you have’. A twelve-person team serving ten million users now pays substantially more than a two-hundred-person team serving fifty thousand — which is the reverse of the old shape.
Any comparison written before this repricing gives the wrong shape of answer, not just the wrong number. If you are evaluating, model your MAU rather than your headcount.
The rest of the field, briefly:
- One major competitor no longer exists independently — it was acquired in 2024 and is now sold as the feature-management module of a broader delivery platform. Any comparison listing it as a standalone vendor is out of date.
- Two open-core options occupy the value position, priced per seat or per API request, with genuinely usable self-hostable cores. The cheaper of them is roughly an order of magnitude below the market leader for equivalent request volume; the trade is thinner experimentation, statistical rigour and enterprise governance.
- And a note on the open-source editions: in at least one case the free self-hosted edition is the reason most people choose the product, and the vendor's pricing page barely mentions it. Read the repository, not the pricing page, if that is your intended path.
The standard, and what it actually buys you
There is now a vendor-neutral specification for flag evaluation, at the incubating tier of its foundation — not graduated, which is worth being accurate about. Every major vendor ships a provider implementation for it.
Here is the honest assessment. It has succeeded at what it set out to do: there is a neutral SDK interface, and your application code no longer names a vendor. What it does not do is make vendors interchangeable.
The evaluation API is standardised. The management surface is not — how you define flags, express targeting rules, build segments, configure approval workflows, and set up experiments is entirely vendor-specific. And that is where all the lock-in lives. Adopting the standard genuinely reduces switching cost, because you rewrite configuration rather than application code. It does not make switching cheap.
So present it as insurance rather than as portability. Adopting it is cheap and sensible; expecting it to make a migration painless is not.
Check yourself