Reach 1% of users before you reach all of them
A release that goes to everyone at once tells you whether it worked at the worst possible moment, at full scale. Turn that single bet into a series of small ones.
Big-bang releases hide their cost until launch day
The failure modes that matter rarely show up in staging. Load only appears at load. Data only gets weird at volume.
Ship to everyone
- The first honest test of the feature is also the most expensive one
- The customer with 40,000 records is not in your test fixtures
- A mistake at 100% is an incident
- One piece of information, delivered too late to act on
Ramp it
- 1%, then 10%, then half, then everyone
- A real chance to stop between each step
- A mistake at 1% is a support ticket
- Same code — only the exposure changed
Deterministic bucketing
Consistency is the whole game
Ramping only ever adds people
Users sit at a fixed position from 0 to 99 per feature. Going from 10% to 25% extends the band — everybody already inside stays inside.
Experiments stay independent
The feature key is part of the hash, so the same unlucky cohort does not receive every rollout you run.
Every service agrees
The calculation is identical in every SDK and on the server, as long as they pass the same bucket key.
Sessions that break, support that cannot reproduce anything, measurement that is pure noise — all of it is an assignment problem, not a traffic problem.
Targeting
Roll out by who, not just how many
const user = new Featureflow.UserBuilder(currentUser.id)
.withAttribute('country', currentUser.country)
.withAttribute('plan', currentUser.plan)
.withAttributes('roles', currentUser.roles)
.build();
// the rules decide; the code just asks
if (featureflow.evaluate('new-search', user).isOn()) {
return searchV2(query, user);
}
return searchV1(query, user);Check the ramp is real
The most common rollout bug is not in your code — it is rule ordering. A broad rule above the percentage rule matches first, and the rollout you think is at 5% is quietly at 100% or at zero.
- 1
Read the counts
Featureflow records evaluation counts per variant. Set 5% and see the new variant answering nothing? The rule above it is eating the traffic.
- 2
Watch your own metrics
Error rate and latency for the cohort on the new path. Those two signals are what a ramp actually needs.
- 3
Make it a process
Every team agrees on the ramp when they design it, then improvises it under deadline. Release pipelines fix that.
Where this goes next
Define the phases once, then stop remembering them
Frequently asked questions
If I move a rollout from 10% to 20%, do the original 10% stay in?
Yes. Hashing salt, feature key and bucket key together gives each user a stable position between 0 and 99 for that feature. Raising the percentage widens the band, so everyone already inside stays inside. Nobody is moved back to the old version because you ramped up.
Does the same user get the same variant across services?
Yes, provided each service passes the same bucket key. The calculation is identical in every SDK and on the server, so your API, web front end and mobile app agree. That is what stops a user seeing the new checkout on the website and the old one in the app.
Can I roll out to a segment rather than a percentage?
Yes, and most teams combine the two. Rules match on any user attribute — plan, country, role, account ID — and those conditions save as reusable segments. A common shape: internal staff first, then beta customers, then a percentage of everyone else, all on one flag.
How do I know the ramp is actually reaching people?
Featureflow records evaluation counts per variant, so you can see how many evaluations returned the new variant versus the old. That catches the most common rollout mistake: a rule higher up the list matching first, so your percentage rule is never reached.
How is this different from a canary release?
A canary routes a fraction of traffic to a different deployment, splitting by request at the infrastructure layer. A progressive rollout splits by user inside a single deployment, so a person consistently gets one experience. The canary proves the build is healthy; the rollout proves the feature is.
Do I need an engineer to change the rollout percentage?
No. There is no percentage, country list or rollout stage in your code — the application asks a question and gets an answer. The rollout plan lives in the dashboard, so changing it needs neither a deploy nor an engineer.
Ramp your next feature instead of launching it
Percentage rollouts, targeting rules and reusable segments are on the free tier — no credit card.
What else Featureflow solves
Kill switch
Turn a bad feature off without shipping a hotfix
Release pipelines
The rollout process runs itself instead of being remembered
Approvals & audit
Answer 'who changed production?' without an enterprise contract
Remote config
Change settings without a deploy or an app store review
Mobile releases
Update the app your users already installed
A/B testing
Split traffic and record what each variant actually did