What you will learn
- How flags separate deployment from release
- Which targeting rules serve which rollout needs
- The build order from flags to rollouts to lifecycle control
- Why stale flags are the most common flag failure
What this project is
Shipping a feature used to mean shipping code and hoping. Feature flags split those steps: code ships dark, then the flag turns the feature on for a percentage, a team, or a segment, and turns it off just as fast if metrics worsen. That control changes release risk from a single event into a dial.
Flags also accumulate. A codebase with hundreds of stale flags becomes harder to read, test, and reason about, since every flag doubles the behaviour paths. The platform must therefore treat flag retirement as a first-class workflow, not a cleanup someday.
Core features
- Flag definitions with types: boolean, multivariate, and configuration flags.
- Targeting rules by user, segment, percentage, and custom attributes.
- Progressive rollouts with scheduled ramps and metric-based pauses.
- Kill switches disabling a feature instantly without redeploying.
- Flag lifecycle tracking: creation, rollout, and retirement with owners.
- Audit logs recording every flag change, who made it, and when.
How it is built
- Basic flags first. Boolean flags with targeting, served to applications reliably.
- Rollouts second, adding percentage ramps and kill switches.
- Lifecycle third. Owners, stale-flag reports, and retirement workflows.
- Governance fourth. Approvals for sensitive flags and audit exports.
- Advanced targeting last. Segments, experiments, and configuration flags.
Technology considerations
Flag evaluation must be fast and resilient: applications cache flag values and fall back to safe defaults when the flag service is unreachable. Targeting evaluation should happen close to the application, using rules synced from the platform, to avoid a network call per flag check. Flag configuration belongs in versioned storage with audit logs, since a flag change is a production change. Costs depend on evaluation volume; confirm with a quote.
- A flag service with cached evaluation and safe defaults on failure.
- Targeting rules synced to applications for low-latency checks.
- Versioned flag configuration with audit logs.
- Stale-flag reporting and retirement workflows.
Challenges to plan for
- Stale flags. Retired features leave flags behind, so ownership and expiry reminders matter.
- Flag sprawl. Hundreds of flags multiply test paths, so flags need justification and review.
- Inconsistent evaluation. Different SDK versions evaluating differently cause user-visible inconsistencies.
- Accidental exposure. A targeting mistake can expose a feature widely, so changes to sensitive flags need review.
A worked example
An e-commerce team wants to redesign checkout, but a single bad release could cost a day's revenue, so the redesign has shipped in tiny, fearful pieces for a year. With feature flags, the team ships the new checkout code dark, then enables it for internal staff, then for five percent of users, watching conversion and error rates at each step, with a kill switch that disables the new checkout instantly without redeploying.
At twenty percent rollout, conversion dips for mobile users on one payment method. The team pauses the rollout, fixes the payment flow, and resumes, without ever exposing the bug to all users or rolling back code. Once the new checkout reaches one hundred percent and stays stable for two weeks, the flag's owner retires it: the flag code is removed, the flag is archived, and the codebase loses a branch it no longer needs. The redesign ships in a quarter, and the team's next risky feature starts with a flag, because the safety net is now routine.
The e-commerce team later uses flags for a pricing experiment, ramping a new discount structure to ten percent of users and measuring revenue per visitor before committing. When the experiment underperforms, the flag turns it off in minutes, and the experiment's data, recorded against the flag's history, informs the next pricing proposal instead of being lost in a reverted code change. Flags become the company's standard way of learning from real users without betting the business on any single release.
Who it is for, and its limits
This fits teams releasing frequently, running experiments, or needing instant kill switches for risky features.
It does not fit a small app with rare releases, where configuration files suffice. It also does not replace testing; a flag hides a broken feature, it does not fix it.
Frequently asked questions
What is the difference between a flag and configuration?
Flags control feature releases with targeting and lifecycle. Configuration sets application behaviour. The line blurs, but flags need targeting, audit, and retirement tooling.
How do kill switches work?
A flag evaluation change propagates to applications, disabling the feature without code changes or redeploys, usually within seconds to minutes.
When should a flag be removed?
Once the feature is fully rolled out and stable, the flag code should be cleaned up and the flag archived, with an owner responsible.
Can flags run experiments?
Yes, with multivariate flags and metric tracking, though dedicated experimentation tooling adds statistical rigour for major decisions.
What happens if the flag service fails?
Applications fall back to cached values or safe defaults, so a flag outage degrades control rather than breaking the application.
When should a feature flag be removed?
Once the feature is fully rolled out and stable, the flag code should be cleaned up and the flag archived, with an owner responsible for retirement.