Feature Flag
A runtime switch that decouples shipping code from enabling behaviour.
A feature flag is a runtime condition that turns behaviour on or off without deploying. Flags are what make Trunk-Based Development and Continuous Deployment practical: unfinished work can be merged and deployed while remaining inert.
Their uses divide into release flags (temporary, removed once a feature is fully out), operational flags (permanent kill switches), permission flags (entitlements), and experiment flags (A/B allocation). Conflating them is how flag systems become unmanageable, since only the first kind should ever be deleted and only the last needs analytics.
Two implementation notes matter more than the mechanism.
Gate at the narrowest point that is actually load-bearing. If every affordance for a feature hangs off one component, one condition covers all of them. But hiding the interface is not sufficient — the write path must be gated too, or the capability is merely undiscoverable.
Verify the off state positively. An absent element is indistinguishable from a page that failed to load. Confirming that the surrounding interface is present on the same load is what makes "the flag is off" a real observation rather than an inference.
Flags accumulate. A flag whose feature has fully shipped is dead conditional logic in every path it touches, and removing it is real work that has to be scheduled.
See also5
Hand-picked in the note itself — the neighbours worth reading next.
Trunk-Based Development
Everyone integrating into one shared branch continuously, with short-lived feature branches.
Version Control & Delivery12 connections
Continuous Deployment
Automatically releasing every change that passes validation.
Version Control & Delivery9 connections
Technical Debt
The future cost of a present shortcut, metaphorically accruing interest.
Method11 connections
Multi-Tenancy
One deployment serving many isolated customers, with tenancy threaded through data, routing, and access.
Data & Content7 connections
Draft and Published
Keeping an in-progress version of content separate from the live one, with all the state that implies.
Data & Content5 connections
Related4
Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.
Linked from7
Notes elsewhere in the wiki that reach for this one.
- Continuous DeploymentVersion Control & Delivery
Automatically releasing every change that passes validation.
- Draft and PublishedData & Content
Keeping an in-progress version of content separate from the live one, with all the state that implies.
- Headless CMSData & Content
A content system exposing structured data through an API, with presentation left entirely to consumers.
- Multi-TenancyData & Content
One deployment serving many isolated customers, with tenancy threaded through data, routing, and access.
- Relational DatabaseData & Content
Data organised as tables with declared relationships, queried declaratively and guarded by constraints.
- Technical DebtMethod
The future cost of a present shortcut, metaphorically accruing interest.
- Trunk-Based DevelopmentVersion Control & Delivery
Everyone integrating into one shared branch continuously, with short-lived feature branches.