Feature flags let you deploy code without releasing it, ship to a subset of users, and roll back a bad change in seconds instead of minutes.
A feature flag (or feature toggle) is a runtime switch that decides which code path executes for which user. Deploy the flag off; enable it for internal users; then 1% of traffic; then 10%; then everyone. If something breaks, flip the switch — no rollback deploy required. The pattern is worth adopting the day you have paying customers.
Release flags — hide unfinished code shipped to main; short-lived (days to weeks); delete once the feature is fully launched. Experiment flags — A/B test alternate implementations; medium-lived (weeks); delete once the winner is picked. Ops/kill-switch flags — long-lived (months to years); disable expensive features under load, cut off a broken integration, defer non-critical work. Permission flags — long-lived; gate features by plan, role, or account. Each has different governance: release flags need aggressive cleanup, ops flags need documentation of when to flip.
(1) Internal-only — enable for employees, dogfood for a day or two. (2) Percentage rollout — 1% → 5% → 25% → 100% with monitoring at each step. (3) Cohort rollout — specific customers, plans, or regions first. (4) Ring deployment — canary tenants, then early-access opt-ins, then general availability. Always pair rollout with monitoring: error rate, latency, and product metric for the flagged path. Automate the abort: if error rate on the flagged code path exceeds a threshold, auto-flip to 0%.
Buy for anything beyond simple boolean flags. LaunchDarkly is the enterprise default (expensive, feature-rich); Statsig and PostHog offer flags + experimentation together; Unleash and OpenFeature are open-source; ConfigCat is the low-cost option. Roll-your-own is tempting and turns into a permanent side project — you'll want percentage rollouts, targeting rules, an audit log, and an SDK for every language, and you'll end up rebuilding a flag platform poorly. Buy from day one; the cost is trivial compared to the incident it prevents.
Every release flag has an owner and a delete-by date at creation. Weekly report: flags older than 60 days without a delete-by date. Monthly ritual: flag cleanup PRs — remove the flag, remove the dead branch, close the ticket. When a flag has been at 100% for 2 weeks, that is your cue to delete. A codebase with 400 flags is one that no one can reason about; a codebase with 40 well-labeled flags is a superpower. Treat flag deletion as a first-class engineering activity, not tech-debt-someday.
Never flag security controls (authentication, authorization, encryption) — a flag flip that turns off authz is a breach. Never flag database migrations one-way — you cannot roll back a dropped column with a flag. Avoid deeply nested flags (flag inside a flag inside a flag) — the combinatorial state space is untestable. Watch out for flag drift across environments (dev, staging, prod diverge silently). And remember: a flag that has never been flipped in production is not tested; run flip drills for critical kill switches.
Investor directory · Fundraising library · Articles A–Z · Company funding database