A feature flag is useful because it separates deployment from exposure. Code can reach production before every customer encounters it. That is a valuable control, especially when a change needs to begin with a small, well-understood group.
But a flag is not a release plan. It cannot decide whether the experience is ready, make a harmful default harmless, explain an unexpected result, or clean up the complexity it adds. Treating it as a safety blanket turns a product decision into a switch someone eventually forgets to turn off.
A deliberate rollout gives the switch a job. Here is the compact contract a product team should agree before enabling it.
Start with the user promise, not the percentage
“Release to 5%” sounds precise, but it does not say what the team is trying to learn. Begin with the outcome the change should create for a defined person. For example: “A returning account owner can invite a teammate without accidentally granting access to billing information.”
That statement gives the rollout a useful first cohort and a reason to observe it. The team can now ask whether invited teammates receive the right access, whether account owners understand the permission choice, and whether support questions or authorization failures increase. A percentage by itself cannot answer any of those questions.
The first cohort should be small because it is meaningful, not merely because it is small. It might be internal users, an opt-in pilot, a customer with the relevant workflow, or a stable slice of eligible accounts. Avoid using a flag to show people a half-finished experience when their feedback cannot lead to a decision.
Make targeting deterministic and explainable
Users notice when an experience changes from one visit to the next. So do support teams trying to reproduce a report. A rollout needs a stable rule for who sees which variation and a record of why that decision was made.
The OpenFeature evaluation-context guidance calls out the targeting key used to identify the subject of evaluation. Many flag systems need that key for deterministic percentage rollouts. Use a stable, privacy-conscious identifier; do not make an email address, browser randomness, or a changing request attribute carry the whole decision.
Keep the rule legible too. “Accounts on the new permissions model that opted into the pilot” is a rule someone can inspect. “A compound condition built from six unrelated attributes” is likely to create surprising exposure and slow down diagnosis. If a support teammate cannot tell a customer which path they were meant to receive, the rollout is too opaque.
Use only the context the decision needs. Evaluation context can be sent to a flag provider, and OpenFeature specifically advises teams to consider how personal data may be handled or persisted. A rollout should not quietly become a new reason to distribute personal data.
Decide the safe state before the first evaluation
Every flag has a failure mode. The provider may be unavailable, its configuration may be malformed, a mobile client may be offline, or a new code path may receive an unexpected value. The question is not whether this can happen; it is which behavior protects the user and the business if it does.
Write that default alongside the product requirement. For a new payment option, the safe default is commonly to keep it unavailable while preserving the existing payment path. For an expensive background task, it may be to avoid starting work. For a security fix, the safe default may be the opposite: enforce the protection even if the usual configuration service cannot respond.
The OpenFeature evaluation API treats a supplied default value as part of flag evaluation, and its no-op provider returns that default. That is a helpful engineering pattern, but the value still has to be a product decision. Test it explicitly: provider available, provider unavailable, stale client configuration, invalid response, and the flag enabled or disabled. A default that has never been exercised is an assumption, not a safeguard.
Observe the decision, not only the error rate
After enabling a cohort, a team needs evidence from both the experience and the system. The recent post-launch measurement plan explains how to follow a user journey after release. A flag adds one essential question to that work: which variation did this person actually receive?
For the promise you defined, capture a small set of signals:
- the flag key, variation, and a non-sensitive cohort identifier;
- the successful user outcome and the step where people abandon or retry;
- request success, latency, and correctness at the boundary the change touches; and
- the reason an evaluation resolved as it did, including errors where the SDK provides them.
OpenFeature’s detailed evaluation result can include the returned value, variant, reason, and error information. That makes it easier to connect a product outcome to the release rule without guessing from logs after the fact.
Do not wait for a complete outage to pause a rollout. Google’s SRE guidance on managing risk frames reliability as a trade-off with delivery speed, not a race toward maximum uptime. Apply that thinking to a rollout: agree on the signal that says “continue,” the signal that says “hold,” and the signal that says “disable and investigate.” A meaningful permissions error, a sharp completion-rate drop, or an unexpected support pattern may matter more than a global average.
Give the flag an owner and an end date
Feature flags are temporary product controls, not permanent architecture. Every flag should have an accountable owner, its purpose, the affected paths, the planned removal date, and a link to the decision that will retire it.
When the rollout has succeeded, remove the inactive branch, stale tests, and targeting rule. When it has failed, capture the evidence, make the safer path explicit, and decide what must change before another attempt. Leaving both paths in place “just in case” increases the test matrix, confuses future changes, and makes it harder to know what customers actually use.
A simple release record is enough:
- Promise: the user outcome being tested.
- Cohort: who is included and why.
- Default: what happens if evaluation cannot be trusted.
- Evidence: the few product and operating signals to watch.
- Decision: the owner, review time, stop condition, and removal date.
That is the difference between using a feature flag as a switch and using it as a release instrument. The flag gives the team controlled exposure. The plan makes that exposure accountable.
If your next release needs product, design, engineering, and quality to make the same decision from the same evidence, bring BugSquad the challenge.