The default is still “ship to everyone.” You merge the PR, the pipeline runs, and within minutes your change is live for every user on your platform. When it works, it’s invisible. When it doesn’t, you’re doing triage at 11pm wondering why you didn’t catch it earlier.
Progressive release is the answer to that question.
What it actually means
Progressive release is the practice of gradually exposing a feature to an increasing percentage of users — starting small, monitoring for issues, and expanding when you’ve built confidence. Not because you don’t trust your code, but because trust is earned in production.
The mechanism is a percentage rollout: each user is assigned a deterministic bucket based on their identifier. If their bucket falls below the rollout threshold, they see the feature. Critically, the same user always lands in the same bucket — so as you expand from 5% to 25%, the users already in the cohort keep their experience. No flickering, no inconsistency.
Three things to hold simultaneously
Percentage targeting is what controls how many users see the feature. Set a flag to 10% and roughly 1 in 10 users get it. Increase to 50% and those same users still see it — plus new ones.
Deterministic assignment is what makes it predictable. A user’s bucket is derived from their key, not random chance. This is what separates a proper progressive rollout from just serving random responses.
Independent per-flag control is what makes the pattern flexible. Each feature flag manages its own rollout on its own schedule. One can be at 50% while another is still at 1%. There’s no batch coordination — flags advance independently as confidence is established for each.
When this pattern fits
Progressive release is ideal when you’re shipping features that can be validated in isolation. If you’re releasing a new recommendation algorithm, a redesigned settings page, or a performance optimization — things where user-by-user exposure tells you what you need to know — this is your pattern.
It’s less suited for coordinated releases where multiple flags need to reach users as a coherent batch. For that, you want something with a gate.
Rollback is just math
Setting the rollout percentage back to 0 immediately removes the feature from all general users. No flag deletion, no code revert, no pipeline run. And if you set it back to 50% later, the same cohort who saw it before will see it again — determinism means you don’t need to reconfigure anything.
That’s the underappreciated half of progressive release: it’s not just a safer way to ship. It’s a faster way to recover.
I built an interactive reference for this pattern — you can step through rollout phases, toggle simulated user segments, and see exactly how evaluation changes at each stage. See the Progressive Release pattern →