Feature toggles

Feature toggle management for engineering teams

Feature toggle, feature flag, feature switch: same mechanism, different words. What separates teams that love toggles from teams drowning in them is not the name, it is the management: naming, environments, cleanup and safe defaults.

No card required

01 · The four kinds of toggle

Not every toggle is the same toggle

Martin Fowler's classic taxonomy still holds: toggles differ in how long they live and how dynamic their decision is. Mixing them up is the root of most toggle debt, because a release toggle managed like a permission toggle never gets deleted.

release.new-checkout

Release toggles

Hide unfinished work so you can merge to main and deploy dark. Lifespan: days to weeks. The moment the feature is at 100%, the toggle is debt: delete it.

Short-lived · delete after launch

ops.heavy-reports

Ops toggles

Control operational behaviour: circuit-break an expensive query, shed load, disable a flaky integration. Lifespan: long. This is where the kill switch lives.

Long-lived · owned by on-call

exp.onboarding-v2

Experiment toggles

Split traffic between variants and measure. Lifespan: exactly as long as the experiment needs statistical significance, then the winner ships and the toggle goes.

Short-lived · ends with the test

perm.sso-enabled

Permission toggles

Gate features by plan, role or entitlement: pro-only features, beta programs, enterprise SSO. Lifespan: permanent. These are product configuration, not debt.

Permanent · part of the product

02 · The discipline

Feature toggle management in five habits

A toggle system fails socially before it fails technically. These habits are what Toggled bakes into the product so they do not depend on anyone's memory.

Name by intent

checkout.new-flow

Namespace by area, name by behaviour. A toggle called temp-fix-2 tells nobody whether it is safe to flip or delete.

Scope per environment

env: prod · staging · dev

The same toggle holds a separate state per environment, so testing ON in staging never leaks a feature to production.

Default to safe

fallback: false

Every toggle declares what happens when nothing answers: the SDK serves the coded default. The safe path is the default path.

Record every flip

audit: who · what · when

When conversion dips at 14:02, the first question is what changed at 14:02. The audit log answers it in one glance.

Delete on schedule

expires: 30d after 100%

Release and experiment toggles get an owner and an expiry review. Stale toggles are untested code paths waiting for an incident.

Swipe sideways through the habits

03 · Toggle debt

The toggle you forgot is the one that hurts you

Every stale toggle doubles the paths through your code, and the OFF path stops being tested the day everyone assumes it is ON. The industry's cautionary tale is a trading firm that reused a long-dead toggle and turned dead code back on in production, with catastrophic results.

The fix is not heroic code review, it is a system that knows which toggles are at 100%, who owns them, and when they were last evaluated, then nags until they are deleted. That is what feature flag tools are for.

Toggle hygiene, live in the console

100% Toggles fully rolled out for 30+ days get flagged for cleanup automatically.
owner Every toggle has an owning engineer; orphaned toggles surface in review.
unused Last-evaluated timestamps expose toggles no SDK has asked about in weeks.
audit Full flip history per toggle, so "what changed" is never archaeology.

Start with how Toggled manages the whole lifecycle, or see a toggle drive a gradual rollout and act as a kill switch.

Early access · launching soon

Toggles managed, named and cleaned up

Toggled is in early access. Unlimited toggles, unlimited seats, flat team pricing at launch. Join the list and we will email you when your spot opens.

No card required · your data stays yours

Keep exploring