Shipping to ten percent of users first
A gradual rollout is an if statement and a stable hash. Ten percent of users get the new checkout, you watch the error rate for an hour, then you move to fifty or you turn it off. Webflow and Bubble do not give you that dial. You click Publish and every visitor gets the change in the same instant, so your rollback plan is noticing fast and clicking Publish again.
A percentage rollout is cheaper than it sounds
OpenFeature describes a feature flag as an if/else statement you can control at runtime, and that is the whole idea. The branch lives in your code. The value that decides which way it goes lives somewhere you can change without a deploy. That one primitive covers canary releases, internal-only features, and killing a broken code path in the middle of an incident without shipping anything.
Unleash buckets users with a normalized MurmurHash of each user's unique ID, so the same person stays on the same side of the branch across sessions instead of flickering between old and new on every page load. Cloudflare solves it one layer down. In Workers, wrangler versions upload creates a version that is not deployed, wrangler versions deploy splits request traffic across versions by percentage, and a rollback is picking the previous version. Workers Logpush exposes a ScriptVersion field so you can attribute errors to a specific version, which is the part that makes the comparison worth anything.
None of that is exotic infrastructure in 2026. The flag is a row in a table and a hash function. The traffic split is a CLI prompt with a number in it. What you buy is that a bad release costs ten percent of users for twenty minutes instead of all of them until somebody notices.
Publish is binary on purpose
Webflow's publish model is clean and it was built to be. You pick the domains in the publish modal, click Publish to selected domains, and the changes are live. Webflow's own help docs describe publishing as pushing changes to the web instantly, and the staging subdomain exists so you can look at the result before you do it. That is a review step, not a rollout. Everyone who visits after you click gets the same page.
Bubble separates Development from Live with two independent databases, and the docs are plain about what deploying does: it transfers the current version of the app from Development to Live, and deploying is instant for all practical purposes. The Live branch is read-only and public. You can isolate work in custom branches, with the number of custom branches set by your plan, and you get a hotfix branch for emergencies, but only Main and hotfix can deploy to Live and the deploy itself is still all or nothing. There is no fifteen percent.
Webflow Enterprise has the closest thing. Page branching gives a branch its own staging subdomain, and design approvals block a merge until required reviewers approve, which is real governance over who can change the site. It still does not split live traffic. Branch staging cannot publish to production, so the final step is the same merge-then-publish to everyone. You can build the percentage yourself with custom code that reads a cookie and swaps a section, and plenty of teams have, but now your rollout logic lives in an embed you cannot unit test and cannot roll back independently of the page it sits on.
What the dial actually changes
The cost shows up in how you behave, not in a line item. When every release is all-or-nothing you batch changes, because publishing is scary and you would rather be scared once a month than once a day. Batched releases are harder to debug: six changes went out together and conversion dropped four percent, so now you are bisecting by unpublishing. Teams that can ship to ten percent ship smaller things more often, and when something breaks the blast radius is already small.
On the Stay World Class migration we replaced Webflow and Xano with Next.js, NestJS and Supabase, and moved the data across in a four stage ETL that mapped legacy platform IDs to PostgreSQL UUIDs so nothing lost its history. Lighthouse went from 55.91 to 91 out of 100 and LCP got 77 percent faster. The performance numbers are the ones a client notices first. The release process is what the team noticed a month later, once deploying stopped being an event.
Cloudflare is also honest about the cost of the dial, which is worth reading before you want one. Running two versions at once creates version skew: consecutive requests from the same user, including page reloads and asset fetches, can hit different versions unless you turn on version affinity. Service bindings make it worse, because Worker A on its new version can call Worker B on its old one with a different API contract. A percentage rollout is a tool for teams that will actually watch the metrics during it.
When the publish button is the right answer
If your site is marketing pages, you do not need a traffic split. A wrong headline is a thirty second fix and nobody's data is at risk. Webflow's staging subdomain plus a careful look is a proportionate process for a careful team, and bolting a flag system onto a brochure site buys you a dashboard to maintain and nothing else.
The same goes for low traffic internal apps. Ten percent of forty daily users is four people, which is not a sample, it is an anecdote. Roll out to everyone, keep the hotfix path short, and spend the effort on backups instead. Bubble's hotfix branch covers the real failure mode there better than a percentage would.
The dial starts to matter when a release can cost money or lose data: checkout, pricing, booking, anything that writes to a record a customer depends on. If you are about to change how payments are taken and your only options are everyone or nobody, that is the moment the ceiling is real. Not before.
