We built progressive rollouts so we'd stop sweating every feature launch

I've been building Zenmanage — a feature flag management platform — and this week we shipped a capability I've wanted since the first version: progressive rollouts.

I want to share what we built and why, because the problem it solves is something every team shipping software runs into eventually, and the decision-making behind the rollout workflow might be useful to other builders here.

The problem we kept hitting

Feature flags already let you separate deployment from release. You deploy the code, then flip the flag when you're ready. But "ready" still means ready for everyone. The flag is binary — on or off.

For low-risk changes, that's fine. But for anything with real blast radius — a new payment flow, a rewritten dashboard, a performance-heavy backend change — flipping to 100% of users on day one is a gamble. If something breaks, everyone is affected. A bug at 1% of traffic is a contained incident. A bug at 100% is a crisis.

We kept running into this ourselves, and we kept seeing the same pattern with teams evaluating the product: they wanted to release gradually, observe what happens, and expand only when the numbers looked right.

What we built

Progressive Rollouts are built directly into our flag targeting system. Instead of on/off, you now control what percentage of users see a change — 1%, 5%, 10%, all the way up. There are two modes:

Manual mode — you set the percentage and advance it yourself. Start at 5%, check your dashboards, bump to 20% after a few hours. You decide the pace. This is the right default for anything high-stakes: payment flows, data migrations, anything where you want a human making the call at each stage.

Automatic mode — the system advances through predefined stages on a daily cadence: 1% → 2% → 5% → 10% → 20% → 50% → 100%. You configure the stages, and Zenmanage handles the progression. You can still pause or complete early at any time. This works well for lower-risk UX changes or internal tooling where you trust the rollout to advance on its own.

Both modes support pause, resume, and instant rollback — no redeploy required.

One technical detail that matters more than it sounds: deterministic bucketing. Each user is hashed to a stable position in a virtual bucket. If a user qualifies at 5%, they stay in the rollout as you ramp to 10%, 20%, 50%. No flickering. No reshuffling. This is critical for a good user experience — nobody wants to see a new checkout flow one moment and the old one the next.

The workflow teams can copy right now

We wrote a full playbook for this, but the short version of the lifecycle is four phases:

1. Configure — Pick manual or automatic. Set the initial percentage. For high-risk changes, start at 1–5%. For internal or low-risk changes, 10–20% is reasonable. Save and activate.

2. Monitor — Watch error rates, p95/p99 latency, business events (conversion, activation), and support volume. Give it at least one full traffic cycle — usually 24–48 hours — before advancing. The first stage is the most important.

3. Expand — If metrics are stable, advance. In manual mode, double the percentage at each step as a rough heuristic: 5% → 10% → 20% → 40% → 80% → 100%. In automatic mode, the system handles it. Soak time at each stage matters more than speed.

4. Complete — When you're at 100% and metrics look good, complete the rollout. This promotes the new value as the flag's published default and clears the rollout state. Then schedule a cleanup ticket to remove the flag from code — leaving flags around indefinitely is how you build tech debt.

The decision matrix we use internally: if error rate spikes and cause is unknown, pause immediately. If the spike is confirmed unrelated, resume and document. If the regression is clearly caused by the rollout, use a kill switch — don't just reduce the percentage. If early data is strongly positive, complete early rather than leaving users on an older code path unnecessarily.

Why I think this matters for small teams especially

Big companies have built internal systems for this — they have release engineering teams and custom tooling. But if you're a small team or a solo founder shipping a SaaS product, you probably don't have the bandwidth to build phased release infrastructure from scratch.

Progressive rollouts turn a high-ceremony release into a routine operation. You ship when you're ready, ramp up gradually, and roll back instantly if something's off. The cost of a bad release goes from "everyone is affected, scramble to fix" to "1% saw it, we paused, we're investigating."

That changes how often you're willing to ship. And shipping more often — safely — is one of the best competitive advantages a small team can have.

I'd genuinely like to hear how other builders here handle phased releases. Are you doing percentage-based rollouts already? Rolling your own? Just yolo-ing to production and hoping for the best? Curious what the range looks like.