What it means
An app team ships a new checkout path behind a flag and first enables it for a small group; if error rates rise, it can stop directing new users to that path. Orders already placed or data already written may still need repair.
Separating deploy from release in this way means code can be present in production while the feature stays off, which controls exposure independently of a full deployment. Google Cloud's feature-flag guide describes targeting attributes and percentage allocations for gradual rollout, and LaunchDarkly documents flag archiving after a flag is no longer needed.
Together these show both the launch control and the maintenance work that follows. Define the audience by account, region, plan or a stable user identifier, avoid accidental exposure of the wrong group, and protect sensitive targeting attributes by limiting collection and access to what is needed.
Set a safe default for when flag evaluation fails, because 'off' may be right for a new checkout but could be unsafe for an emergency control. Use stable allocation so a percentage rollout does not change a person's experience on every page load, and measure actual exposure, since 5% of eligible users is not necessarily 5% of all customers.
Test both the old and new paths and any flag combinations real users may see, because a flag that is 'off' in development can hide a broken fallback. Set success criteria and stop criteria in advance, using error rate, transaction completion and support tickets, because a rollout percentage alone says nothing about quality.
Assign an on-call owner so that someone can see a failure signal promptly, and record metrics by variant, since aggregate conversion can mask a failing flagged group. Expand exposure in stages at a pace that suits the transaction risk, rather than relying on a vague 'looks fine' review.
Plan rollback by knowing which flag state stops new exposure and how long it takes to propagate, and test the control before relying on it. A feature that changes database records, charges customers or sends messages may have effects that turning off a flag cannot reverse, so design recovery separately.
Do not equate rollout with an experiment, since an A/B test needs hypotheses, randomisation and analysis, and invited beta testers may be more tolerant or technically skilled than ordinary users. Governance keeps flags from becoming hidden risk: only authorised people should change production flags, with a record of who changed a rule, when and why, and an inventory should list purpose, owner, audience, default state and planned removal.
Support staff, marketing and legal should know which customers can see a feature, so copy and contractual claims match actual exposure and regional or data residency requirements are validated beyond a UI switch. For owners, a feature flag is a release-control tool, not a guarantee of safety, and old or emergency flags should be reviewed against an owner and expiry date, then archived once the feature is fully accepted.
In practice
Real-world examples.
Example
A retailer enables a new checkout for 5% of eligible users with error monitoring and an on-call owner. Exposure is allocated by a stable customer identifier, so the same shopper always sees the same version. The team reviews error rates and completed orders before moving to 20%.
Example
A support team in a software-as-a-service business gives beta access to named customer accounts that asked for an early look. Support staff can see which accounts have the feature, so they give consistent answers. The accounts agree that feedback from them may not represent typical customers.
Example
An obsolete rollout flag is archived after both code paths are reviewed and the old path is removed from the code. The owner confirms that no other flag depends on it. The inventory entry is updated with the removal date.
Formula
Calculation
Rollout share = exposed eligible users / all eligible users x 100. Actual exposure should be counted from logs, not read from the configured percentage.
Worked example: 5,000 of 100,000 eligible users are exposed, so rollout share = 5,000 / 100,000 x 100 = 5%. If the company has 250,000 customers in total, the same 5,000 users are 5,000 / 250,000 x 100 = 2% of all customers, which is why the denominator must be labelled.
Stop-criteria example: during the rollout the flagged group generates 5,000 checkout sessions with 150 errors, an error rate of 150 / 5,000 x 100 = 3%. The other 95,000 sessions have 1,900 errors, a rate of 1,900 / 95,000 x 100 = 2%. If the team agreed in advance to pause when the flagged error rate is more than 0.5 percentage points above the control, the 1 point gap triggers a pause.Case study
Seen in the real world.
Entirely fictional case: Orbit Delivery, an invented company, launched a payment redesign to a small eligible group of customers. Its team set a stop criterion in advance, watched completion and error measures and had a tested off-switch for new sessions. When the error rate in the flagged group rose above the agreed limit, the team turned the flag off within minutes.
It then found that a handful of payments had been submitted twice, and a separate recovery process, not the flag, was needed to refund them. The case does not assume that reversing a flag would undo completed payments or recover all customer impact. It is illustrative, and the lesson is that the off-switch and the recovery plan are two different controls.
Watch out
Common mistakes.
- Assuming a flag off-switch reverses transactions or data changes.
- Using unstable targeting that switches users between experiences.
- Leaving obsolete flags in code without an owner or removal plan.
Questions
People also ask.
What is a feature flag?
A controlled condition that determines which users see a software behaviour.
Why use one?
It can support staged releases and targeted access, with monitoring and rollback planning.
What is the risk?
Old flags add complexity, and switching off may not reverse prior side effects.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%