A feature flag is not a launch strategy by itself. I have seen teams add flags because they want a safer release, then still ship with no owner, no metric, no rollback decision, and no cleanup date. The flag only moved the risk from deploy time to decision time.
The useful question is smaller: what is the lightest rollout control that matches the risk of this change? That framing keeps delivery calm without turning every product change into ceremony.
The ladder I would use
I would pick from five rungs, in this order.
| Rung | Use it when | Stop condition |
|---|---|---|
| Direct release | The change is reversible and low blast radius | Normal deploy health stays clean |
| Manual gate | A human needs to verify timing or readiness | Reviewer approves the production job |
| Percentage rollout | You need limited exposure, not automatic judgment | No critical regression at the first cohort |
| Progressive rollout | Exposure should increase on a schedule | Each stage passes the written health check |
| Guarded rollout | A metric should stop promotion automatically | Regression threshold trips or final stage completes |
This keeps the control matched to the risk. Manual gates, feature flags, and guarded releases all have carrying cost. The cheapest real stop point usually wins.
Start with the deploy gate
Before I reach for feature flags, I check whether a deployment gate is enough.
GitHub environments support required reviewers, wait timers, branch restrictions, and custom protection rules driven by GitHub Apps. That covers launches where the real risk is timing, coordination, or compliance signoff.
Write the gate as a decision, not a vague pause: who approves, what evidence they inspect, what rejection means, and when the pending deployment becomes stale.
This pairs well with the release-note discipline I wrote about in the release note gate for calmer launches. The deploy gate asks whether the change is ready to go out. The release note gate asks whether the shipped behavior is understandable after it goes out.
Use percentage rollouts when exposure is the question
A percentage rollout is enough when the product question is simply, "can a small slice use this without obvious damage?"
Vercel Rolling Releases are a good example at the deployment level. A production promotion can send a configurable fraction of traffic to the release candidate while the rest stays on the prior deployment. Vercel also recommends Skew Protection with Rolling Releases so the client and backend stay matched during a mixed deployment window.
That last detail matters. Many rollout bugs are version-skew bugs: a browser has one bundle, an API route has another assumption, and the user falls into the gap. Vercel's forced canary cookie is useful for internal checks, but the docs are clear that a user can set the canary-forcing query parameter. Treat that path as a convenience, not a security boundary.
Use feature flags for behavior, not deploy fear
Feature flags are best when the thing you are releasing is behavior inside a running system: a new onboarding step, a recommendation model, a billing rule, or a search ranking change.
OpenFeature's evaluation context is the right mental model. A flag decision depends on context about the subject of evaluation, and the spec says that context includes an optional targeting key. If your app cannot consistently provide the same user, account, workspace, region, plan, or session identity, your rollout will be noisy before the product learns anything.
That is why I like a small flag contract on any meaningful launch:
export type LaunchContext = {
targetingKey: string;
accountId?: string;
plan?: 'free' | 'pro' | 'enterprise';
region?: string;
};
The point is forcing the team to name the segmentation basis before the flag goes live. Without that, percentage rollout numbers look precise but mean very little.
Pick progressive only when time helps
Progressive rollouts are useful when time adds signal. LaunchDarkly describes progressive rollouts as increasing the percentage served to a variation over a configured schedule. Its docs also separate progressive rollouts from guarded rollouts: progressive rollouts do not include metric monitoring or absolute difference charts, while guarded rollouts are meant to monitor regressions.
That distinction is the product decision.
Use progressive rollout when the team will actively watch the release and the next stage is still a human judgment. Use guarded rollout when a metric should have authority to halt promotion. Do not pretend a timed rollout is safer just because it moves slowly. A slow rollout with no stop rule is just a delayed full release.
A practical progressive plan can fit in one ticket:
- Start at 5 percent for two hours.
- Check error rate, conversion start rate, support tickets, and one product event.
- Move to 25 percent only if all four are acceptable.
- Promote to 100 percent the next business morning.
- Remove the flag within two weeks if the launch holds.
Write the cleanup date before launch
The most expensive flags are the ones that succeed and never leave.
Unleash's flag type guidance is useful here because it gives flags expected lifetimes. Release and experiment flags are short-lived, operational flags are even shorter, while kill switches and permission flags may be permanent. I do not treat those numbers as universal law, but I do like forcing a type at creation time.
A flag without a type should not ship. A release flag with no cleanup owner should not ship either.
This is also where product and engineering meet. The product owner knows when a launch decision is done. Engineering knows where the flag lives in code, tests, dashboards, and docs. The cleanup task should sit beside the original implementation task, the same way agent-ready issues need acceptance criteria before an agent starts coding.
The takeaway I want on the ticket
For the next feature-flagged launch I run, I want one small block in the ticket:
- Control: direct release, manual gate, percentage rollout, progressive rollout, or guarded rollout.
- First audience: who sees it first and why.
- Health check: the metric or observation that decides promotion.
- Rollback: who can stop it and how.
- Cleanup: the flag type, owner, and removal date.
That is not a release-management program. It is a cheap habit. The next wave of delivery tooling will keep making rollouts easier to configure, but the hard part will stay the same: deciding what evidence is enough to let the next cohort in.