Feature Toggle vs Branching: How to Choose

Feature toggle vs branching: the one-paragraph answer

A feature branch controls what code enters main before it merges. A feature toggle controls what users see after the code is already deployed. Because the two mechanisms act at different points in the lifecycle, they are not substitutes for each other. If your question is “how do four developers work in parallel without breaking each other,” you want a branch. If it is “how do I ship this without exposing it, and switch it off in seconds when it misbehaves,” you want a toggle.

The costs deserve equal billing. Branches charge you integration pain and all-or-nothing deploys. Toggles charge you codebase complexity, doubled test paths and a cleanup obligation most teams never honour.

Key takeaways

• Branching is pre-merge code control; toggling is post-deploy runtime control.
• Branch lifetime, not branching itself, is what produces merge hell.
• Ten independent boolean flags describe 1,024 possible configurations. Nobody tests 1,024 configurations.
• Release toggles should not outlive a week or two, per Martin Fowler’s guidance; permissioning toggles can live for years by design.
• A five-engineer team on one codebase can do this with a config file and buy nothing.

What a feature branch actually gives you (and where it stops)

The mechanic is unglamorous: branch from main, commit, open a pull request, get code review, merge. Three named strategies wrap that loop. Gitflow adds develop, release and hotfix branches for versioned software. GitHub Flow strips it back to one long-lived main plus short-lived branches deployed on merge. Trunk-based development asks that every short-lived branch reach trunk inside a day or two. Our guide to Git branching strategies walks the variants, GitLab Flow included, on GitHub, GitLab and Bitbucket.

What branching buys is worth stating without sneering. Parallel work isolation, so an unfinished refactor cannot break a colleague’s build. A review gate before anything touches main. Continuous integration running on the branch itself, whether that is GitHub Actions, GitLab CI or Jenkins, so you see test results before the merge rather than after. Cheap abandonment: delete the branch and nothing shipped, no dead conditional left behind.

The hard stop arrives at merge. Once the artifact is deployed, branching gives you no further control whatsoever. Recovery narrows to redeploying the previous artifact or rushing a forward fix, both measured in minutes to tens of minutes on a healthy pipeline, hours on an unhealthy one.

The usual caricature is that branches are long-lived and therefore bad. The real variable is lifetime. A branch merged within a day behaves almost nothing like one merged after six weeks, because every commit landing on main while you are away is a commit you have not integrated against. Elie Nehmé’s widely shared “Kill Feature Branching or Die Trying” post takes the strongest anti-branch position in the corpus, then concedes in a footnote that short-lived branches merged quickly are valid practice. That concession is the actual finding.

One housekeeping note while we are in Git. Since version 2.23, git switch and git restore have superseded git checkout for branch work, splitting an overloaded command into two clear ones, and the official git switch documentation still marks both experimental. Much of the branching tutorial corpus has not caught up. The most-starred interactive Git branching tutorial on GitHub carries an open issue titled “Time to switch to switch?” with 21 reactions, filed by an instructor teaching Git at Paris-Dauphine University.

Here is the asymmetry that matters when you weigh feature toggle vs branching. Branching ships inside Git, so one tool at one version is your whole dependency surface. Toggling is a pattern you implement, so the surface is your own code plus whatever control plane you point it at. One of those surfaces is maintained by somebody else for free.

Figure 1. Branching’s control ends at deploy. Toggling’s begins at request evaluation. Both new Git commands remain experimental per the release notes.

What a feature toggle actually gives you (and what it charges you)

Fowler’s vocabulary is the field’s shared vocabulary, so use it. A conditional sits at a toggle point. It asks a toggle router, which consults toggle configuration (hardcoded constant, config file, database row, or a distributed service) against a toggle context (the current user, their plan, their device, a random bucket). The router returns a decision and the code path is selected at runtime. The decision point is deliberately decoupled from the decision logic, which is why scattered if (FLAG_X) reads of a global are the anti-pattern version of this.

What toggles buy that no branch can: deploy dark, with the code in production and visible to nobody. Enable for employees only. Ramp 1% to 5% to 100%, which LaunchDarkly describes as the standard risk-limiting progression (vendor guidance, not a standard body’s). Target by plan, geography or device. Kill in seconds with no deploy. Attribute an incident to one named feature rather than to a bundle of eleven merged PRs.

Now the bill.

Every live toggle is a permanent conditional in your source, an extra configuration entry, and a new runtime dependency. The test matrix is the part vendor pages skip. With n independent boolean flags, reachable configurations number 2^n: four flags give 16, ten give 1,024, twelve give 4,096. No team validates that. The honest strategy is testing two configurations, the one in production and the one you intend to ship next, and accepting that everything else is unvalidated by choice rather than by accident.

Figure 2. Configurations = 2^n. Twelve flags describe 4,096 states; teams test two.

Toggle debt is what accumulates when flags outlive their purpose, because deleting a flag ships no user-visible value and nobody is measured on it. Fowler’s guidance is that release toggles “should generally not stick around much longer than a week or two.” LaunchDarkly’s published rule of thumb is to wait one to two weeks after full rollout, then remove the flag in the next development cycle. Neither page specifies who owns the deletion ticket, and that omission is the mechanism of the debt. Our flag cleanup checklist assigns it.

The catastrophic version is in Fowler’s own article, which cites Knight Capital Group’s $460 million loss as a cautionary tale about dead code reactivated by stale configuration. The SEC’s 2013 administrative proceeding against Knight Capital is the primary document and worth reading in place of any retelling: the defective router code had been dormant since 2003, and a 2012 deployment to seven of eight servers left one running the old path with a repurposed flag set.

The runtime dependency is real too. A hosted flag service sits in your request path or your SDK’s bootstrap path, and the market treats that as a design concern rather than a hypothetical: Harness publishes a relay-proxy architecture, and local-evaluation modes exist across the category specifically so applications survive control-plane unavailability. Treat any vendor’s uptime comparison against a named competitor as marketing.

The four kinds of toggle, and why conflating them is the actual mistake

Pete Hodgson’s taxonomy, published on martinfowler.com in October 2017, is the single most useful idea in the literature. Statsig correctly attributes the four categories and then adds nothing to them. Here they are with the columns the corpus drops: owner, removal trigger, and whether the thing is debt at all.

Toggle type	Longevity (Fowler)	Dynamism (Fowler)	Owner (our recommendation)	Removal trigger (our recommendation)	Debt?
Release toggle	Days to weeks	Static per deployment	Engineer who added it	Full rollout plus agreed soak period	Yes, after soak
Experiment toggle	Length of the experiment	Per-request cohorting	Owner of the hypothesis	Statistical significance reached, or result invalidated	Yes, immediately after readout
Ops toggle	Weeks to permanent	Per-request or manual	SRE / on-call	Only when the subsystem it protects is retired	No, it is a control
Permissioning toggle	Months to years	Per-request	Product / billing	Plan or entitlement discontinued	No, it is product surface

Release toggles hide incomplete work so trunk stays deployable. Experiment toggles drive A/B and multivariate testing in tools like Statsig, Optimizely, Eppo or GrowthBook, and must live long enough for significance but not so long that unrelated changes invalidate the comparison. Ops toggles are manually managed circuit breakers; Fowler describes an online retailer pre-emptively disabling non-critical features in the purchase flow ahead of a high-demand launch, which is the canonical kill switch story. Permissioning toggles gate entitlements.

Why the conflation hurts: a permissioning toggle hard-deleted by an over-zealous cleanup sprint is an outage and possibly a billing incident. A release toggle left in for a year is rot. Same mechanism, opposite correct treatment, and a single “stale flags” dashboard that does not distinguish them will eventually recommend the outage.

Figure 3. Hodgson’s four categories, 2017, with the ownership and removal columns the secondary coverage drops.

Side-by-side: branch vs toggle across twelve dimensions

Dimension	Feature branch	Feature toggle
Control point	Pre-merge: what code enters main	Post-deploy: which path executes at runtime
Decision timing	At merge, by a human reviewing a diff	At request time, by the toggle router
Reversibility	Revert the merge commit or redeploy prior artifact	Write one config value
Time to rollback	One deploy cycle: minutes to tens of minutes	One config write: seconds, no artifact rebuild
Blast radius	Whole artifact, every change in that deploy	One named feature, one targeted cohort
Who can operate it	Engineer with merge and deploy rights	Engineer, PM or on-call via the flag UI
Audit trail	Signed commit, PR history, review approvals	Whatever your platform logs; absent on hand-rolled flags
CI cost	One pipeline run per branch, plus the merge run	Pipeline must run against two or more flag states
Test matrix impact	Linear: one branch, one configuration	Combinatorial: 2^n configurations exist
Code cleanliness	Clean after merge, no residue	A conditional plus a config entry until deleted
Cost at rest	Zero once merged	A conditional, a config entry and a test path, forever
Failure mode when misused	Merge hell, big-bang integration, all-or-nothing deploys	Toggle debt, latent code nobody can account for

LaunchDarkly’s published comparison is accurate as far as it goes: four rows covering control point, timing, flexibility and scope. It carries no row on cost, risk or the test matrix, the predictable gap when a page exists to sell flags.

The dimension both sides underweight is who can operate the mechanism under stress. A branch rollback needs somebody with merge and deploy rights, awake, with a working pipeline. A flag flip needs somebody with a browser. At 3am those are not the same requirement, and the second one is why teams adopt flags long before they have a test-matrix problem.

Figure 4. The same fortnight of work, two control models, with the rollback mechanism marked at each stage.

The decision matrix: which one, for your team, right now

Team shape	Monthly release	Weekly release	Daily release	Continuous deploy
Solo or 2–5 devs, one codebase	Short-lived branches only	Short-lived branches only	Branches + config-file release toggles	Trunk + release toggles
10–50 devs, one codebase	Branches + release toggles	Branches + release toggles	Trunk + toggles mandatory	Trunk + toggles mandatory, platform likely
50+ devs, multi-team monorepo	Release branches + toggles	Trunk + toggles mandatory	Trunk + toggles mandatory	Trunk + toggles + percentage targeting
Open source with external contributors	Long-lived contributor branches, maintainer merges	Same, plus toggles for risky subsystems	Same	Rarely applicable
Agency, fixed-scope client projects	Short-lived branches, per-client release branch	Branches + permissioning toggles per client	Branches + toggles	Uncommon

Five cases where a long-lived branch is still correct, which no ranking competitor will tell you. Maintaining a release or LTS line that receives backported fixes via git cherry-pick. A fork you intend to keep diverged. An external contributor’s pull request, whose lifetime you do not control. A spike you expect to throw away. And a refactor so invasive that toggling both paths doubles the surface area you were trying to simplify, where branch by abstraction wins: introduce an abstraction layer, migrate callers behind it on trunk, delete the old implementation. The abstraction is the thing you wanted anyway. The toggle is scaffolding you will have to remove.

Toggles are effectively mandatory for mobile binaries, for multi-tenant SaaS with per-customer rollout commitments, for anything carrying a regulatory kill-switch obligation, and for any team whose rollback story is “redeploy and hope.”

The threshold heuristic is blunt. If the work cannot be merged safely within about two days, you need either a toggle or a smaller slice of work. “A longer branch” is the third option that always looks cheapest and never is.

You have mixed them up if you are toggling something only you will ever see, or branching something that needs a production kill switch.

Figure 5. This page’s original synthesis of the grid above.

The combined workflow, step by step

1. Cut a short-lived branch with git switch -c.
2. Create the flag and its removal ticket in the same pull request, with a due date and a named owner. This step decides whether you accrue toggle debt.
3. Wrap the new behaviour at the toggle point before you write the feature. Retrofitting a toggle around finished code is where scattered conditionals come from.
4. Merge to main within two days, flag default-off.
5. Deploy. The code is live and inert: a dark launch.
6. Enable for internal users via a header-based or employee-attribute rule.
7. Ramp by percentage. Fowler describes the canary cohort as a random 1% sample, commonly a modulo of user ID, with the other 99% held on the existing path for comparison. LaunchDarkly’s published progression is 5%, then 10%, then everyone. Watch error rate, latency and the one business metric you agreed on before the ramp started.
8. Hold at full rollout for the agreed soak period.
9. Delete the flag, delete the dead branch of the conditional, close the cleanup ticket.

Automated code-reference scanning, shipped by several platforms, is how teams find orphaned flag reads that configuration no longer knows about. The capability is real; treat efficacy claims as marketing.

Database migrations and API contracts are the case every competitor skips, because they cannot be toggled off as cleanly as UI. Use expand-contract: add the new column or endpoint, dual-write behind the flag, backfill historical rows, move reads to the new path behind the flag, then remove the old column and the old write. The flag protects the read path only. Your already-migrated schema is not coming back when you flip it off, which is why the expand step must be backward compatible on its own merits.

Testing fits at steps 4 and 7. Any flag on a critical path needs both states exercised in CI. Fowler makes the point directly: toggles introduce validation complexity, and you often need to test multiple code paths for the same artifact.

Observability belongs in the same breath, and almost no comparison page says so. A flag flip is a production change that leaves no commit behind, so your dashboards need the flag name and its state as a dimension on error rate and latency. Otherwise step 7 degrades into watching a graph move and guessing which of the day’s twenty flag changes moved it. Google’s SRE book chapter on canarying treats this as a precondition rather than a nicety.

Figure 6. Ramp percentages per LaunchDarkly, soak guidance per martinfowler.com, ticket-at-creation is this page’s recommendation.

Implementation: Python, .NET, Android and a plain no-platform version

Start with no platform at all, because toggles are a pattern before they are a purchase.

# toggles.py — the whole pattern in ~20 lines
import json

class ToggleRouter:
    def __init__(self, config: dict):
        self._config = config

    def is_enabled(self, name: str, context: dict | None = None) -> bool:
        rule = self._config.get(name)
        if rule is None:
            return False                      # safe default: off
        if isinstance(rule, bool):
            return rule
        if "user_ids" in rule and context:
            return context.get("user_id") in rule["user_ids"]
        if "percentage" in rule and context:
            return hash(context["user_id"]) % 100 < rule["percentage"]
        return False

def from_file(path: str) -> ToggleRouter:
    with open(path) as fh:
        return ToggleRouter(json.load(fh))

One caveat on that percentage line, since it is the bug every hand-rolled router ships with. Python randomises hash() for str inputs per process unless PYTHONHASHSEED is fixed, as the PYTHONHASHSEED documentation spells out, so different workers bucket the same user differently. Use hashlib.md5 on the user ID instead, or any stable hash, and your cohorts stop drifting.

The router is injected, never read from a global. That is what makes the two-test pattern trivial:

def test_feature_off():
    svc = CheckoutService(ToggleRouter({"new_pricing": False}))
    assert svc.quote(cart) == legacy_quote

def test_feature_on():
    svc = CheckoutService(ToggleRouter({"new_pricing": True}))
    assert svc.quote(cart) == new_quote

Two tests per flag on a critical path. That is the realistic answer to the 2^n problem.

For .NET, Microsoft.FeatureManagement.AspNetCore gives you IFeatureManager, declarative [FeatureGate] attributes, and custom IFeatureFilter implementations for routing logic, backed by Azure App Configuration if you want it. The library ships three filters, percentage and time-window among them, so the only one most teams write by hand is the targeting rule. A header-based filter is the standard trick for internal testers in production: the tester sends X-Feature-NewCheckout: on, the filter honours it, everyone else gets the default. Nehmé publishes a working sample at github.com/elie29/Feature-Toggles alongside the Medium post; read the repository rather than a reproduction of it.

Android and iOS are where feature toggle vs branching stops being close. You cannot redeploy a binary. App-store review latency means a code-based fix stays unavailable for days while the bad build keeps running, so a remote toggle is the only fast rollback you have. Four design requirements follow:

• Flag state must be fetched and cached locally, so the app works offline.
• Every flag needs a safe default for first launch, before any fetch completes.
• Cached state must survive cold start, or your kill switch is only as reliable as the user’s network at launch.
• A flip only reaches users whose app has re-fetched configuration. The stale-config window is part of your rollback SLA.

Platform defaults set the floor. Firebase Remote Config uses a 12-hour minimum fetch interval by default, so a flip can take half a day to reach a client unless you shorten the interval or ship real-time updates. Google Play’s staged rollout is a percentage of installs, not a runtime switch, so rolling back halts new installs and leaves existing ones on the bad build. That asymmetry is the entire argument for carrying a flag SDK on mobile.

How long the stale window actually runs depends on your SDK’s polling interval, streaming support and cache policy, and it needs measuring against your own app. This page has not measured it. What you would instrument: time from config write to effective change across cold start, warm resume and background fetch, at the 50th and 95th percentile.

Figure 7. Config and caching behaviour described from two mobile SDKs’ published docs. No measured fetch times.

Git-backed configuration is the middle ground between a hardcoded constant and a SaaS control plane. Flipt serves flag state from declarative stores including Git, OCI registries and object storage (137 points on Hacker News). Dorkly backs LaunchDarkly SDKs with YAML files in GitHub as the source of truth (304 points on Hacker News); its author discloses being a former LaunchDarkly employee. The trade is clean: review, diff and audit on every flag change for free, and you give up sub-second flips and sophisticated per-user targeting.

OpenFeature, a CNCF incubating project since 2023, is the vendor-neutral SDK layer worth knowing before you decide whether you need a platform at all. Writing against its API makes the provider a swap rather than a migration, the cheapest lock-in insurance available to a team that has not yet committed. Its specification defines the evaluation API, provider interface and hooks, and the major platforms publish providers against it.

What practitioners say when there’s no vendor in the room

A Hacker News commenter describes the hybrid exactly as it runs in the wild: “When there is a feature that is not done yet, but has some user-facing code, we use feature toggler to disable it on production,” followed by “we deploy quick fix by doing a cherry-pick.” The same thread records them calling their branching approach “still not satisf[ying].” Real teams run toggles, cherry-picks and branches at once, and are not fully happy with any of it. The conclusion that supports is “this is messy” rather than “buy this,” which is why no vendor page carries it.

On the branching side, pcottle/learnGitBranching carries over 34,000 stars and an MIT licence. Its highest-engagement open bug, at 73 reactions, is learners unable to progress past the goal window on the very first lesson. Its top community thread, at 956 reactions, is gratitude for making people “fearless in terms of git branching.” The narrow claim those support: branching fluency is unevenly distributed, and a workflow your team cannot operate confidently is not a workflow.

DORA’s State of DevOps research supplies the one industry-scale data point worth carrying into the feature toggle vs branching argument. Its four delivery metrics, deployment frequency, lead time for changes, change failure rate and time to restore service, are what any toggle-or-branch decision should move. Trunk-based development has been a measured predictor of delivery performance across DORA’s reports, which is why the branching question is not merely stylistic. See our breakdown of the four DORA metrics for what to instrument first.

We have not characterised Reddit or Hacker News consensus here, and nobody should. Every practitioner view above has a linked thread you can read yourself.

Build vs buy: what a flag platform costs you versus branching for free

Branching costs zero marginal dollars. It is already in your Git host. Toggles are free as a pattern and priced as a platform, across three tiers.

Tier	What you get	What you pay	5 engineers	40 engineers	200 engineers, SSO/SCIM/audit
Hand-rolled config flags	Boolean and percentage routing, deploy-to-change or config-reload	Engineering time only	Sufficient	Strained: no audit, no UI	Not viable
Self-hosted OSS (Flipt, Unleash, Flagsmith OSS, GrowthBook)	UI, targeting, API, your own database	Infra plus operational ownership	Overkill	Reasonable fit	Fit, if you want control-plane on-call
SaaS (LaunchDarkly, Statsig, Harness, Split, Optimizely, Eppo, PostHog, ConfigCat)	Managed control plane, SDKs, audit log, code references	Per-seat and/or per monthly tracked user	Rarely justified	Common choice	Common choice, enterprise tier quote-only

Every number in a published cost model goes stale. Pull each figure from the vendor’s own pricing page on the day you build the model, stamp it with the URL and the date you read it, and record anything behind a “contact sales” wall as quote-only rather than estimating it. Licensing is more stable and worth checking first: Unleash and Flipt both publish open-source editions, and the self-hosted licence terms decide whether that tier is available to you at all.

Four costs never appear on a pricing page: engineering hours to instrument toggle points properly rather than scattering conditionals, per-flag cleanup overhead multiplied by however many flags you create a quarter, extra CI minutes from running two flag states, and the on-call burden of owning a self-hosted control plane your application depends on at bootstrap, Kubernetes manifests included.

Lock-in concentrates in exactly the features that justify the enterprise tier: SCIM user management, relay proxies in your VPC, long audit-log retention. Those are what you cannot export. Migration guides between platforms exist, and they are marketing artifacts published by the destination.

A five-engineer team on one codebase deploying weekly should write the 20-line router above, keep flag state in a JSON file under review, and buy nothing.

Figure 8. Footnote every price with the vendor pricing-page URL and date accessed; size self-host infra from each project’s deployment docs; mark sales-wall tiers quote-only.

Branching strategy, decided: Gitflow, GitHub Flow or trunk-based

Trunk-based development with short-lived branches plus release toggles is the default for teams deploying continuously. GitHub Flow is the simplified version for teams with one production environment and no supported versions behind them. Gitflow, which Vincent Driessen published in 2010 and later annotated with a note steering readers toward simpler models for continuously delivered web software, earns its complexity in one situation: you ship versioned software with release lines you have promised to support, and backported fixes need somewhere to live.

The causal link vendor pages assert without showing: trunk-based development is not achievable without toggles for any feature taking longer than a couple of days. If the work cannot merge daily and you have no mechanism to hide incomplete behaviour, you are back on a branch. Toggles are the enabling mechanism for trunk-based development, not an optional add-on.

The failure mode of adopting trunk-based without flag discipline is specific and common. Main fills with half-finished latent code. Nobody can say which paths are live for which users. You have traded merge debt for toggle debt one-for-one, and the new debt is harder to see because it never announces itself as a conflict. DORA metrics will show deployment frequency rising while change failure rate quietly follows it.

Repository shape changes the weighting. A monorepo makes short-lived branches cheaper, because everything builds together, and makes cross-team conflicts more frequent, because everyone edits adjacent files. Both effects push toward toggles. A polyrepo setup tolerates slightly longer branches inside a service boundary and pays for it at the integration seam.

Frequently Asked Questions

What is the difference between feature branching and branching?

Branching is the general Git mechanic of creating a divergent line of development. Feature branching is one strategy for using it: one branch per unit of work, merged back after review. Release branches, hotfix branches and long-lived fork or LTS lines are branches that are not feature branches.

Which branching strategy is best?

Trunk-based development with short-lived branches merged at least daily, plus release toggles, is the best default for teams deploying continuously. Gitflow earns its extra complexity only when you maintain multiple supported release versions. Trunk-based is not viable without toggles for work lasting more than roughly two days.

What is a toggle feature?

A toggle feature is a conditional that selects between code paths at runtime based on external configuration, letting you deploy a feature switched off and enable it later without redeploying. Fowler lists feature flags, feature bits and feature flippers as synonyms. Example: an ops kill switch disabling product recommendations under load.

Are feature branches a good idea?

Yes, when short-lived: hours to a couple of days. They become a liability as they age, because divergence from main compounds into merge conflicts and rework. If the work cannot be merged in two days, split the work or put it behind a toggle.

Is a feature toggle the same as a feature flag?

Yes. martinfowler.com/articles/feature-toggles.html lists feature flags, feature bits and feature flippers as synonyms for the same set of techniques and uses the terms interchangeably. Some vendor pages construct a technical distinction between toggle and flag; read that as a terminology land-grab.

Do feature flags replace feature branches?

No. Flags give you no code review, no isolation during active development, and no clean abandonment. They replace the release function of a branch, not its collaboration function. Long-lived branches remain correct for supported release lines, forks, external contributor pull requests and throwaway spikes.

How long should a feature flag live?

It depends on category, not on a single number. Release toggles: a week or two, per Fowler. Experiment toggles: only as long as significance requires, since later changes invalidate results. Ops kill switches: indefinitely by design. Permissioning toggles: years, because they are product surface. Enforce it by creating the removal ticket in the flag’s own pull request.

What is toggle debt and how do you avoid it?

Toggle debt is the accumulated cost of flags that outlived their purpose: dead conditionals, untested code paths, and configuration nobody dares change. Three controls work. Create the removal ticket at flag creation. Run automated code-reference scanning for orphaned flag reads. Name an owner per category. Fowler cites Knight Capital as the worst case of reactivated code behind stale configuration, and the SEC’s 2013 order is the primary account.

Can you use feature flags for mobile apps?

Yes, and they matter more on mobile than on web, because you cannot redeploy a binary and app-store review latency makes a code-based fix take days. Configuration must be cached locally, every flag needs a safe offline default, and a flip only reaches clients that have re-fetched, so the stale-config window belongs in your rollback SLA. Firebase Remote Config’s 12-hour default fetch interval is the kind of number that decides how fast your kill switch really is.

Does feature toggle vs branching change for open-source projects?

Yes, in the direction most comparison pages ignore. You do not control a contributor’s branch lifetime, so the short-lived-branch rule is unenforceable at the edges of the project. Toggles help for risky subsystems a maintainer wants merged but not yet default-on, which is close to how long deprecation cycles work in practice.

---

Whichever side of feature toggle vs branching you land on, do this one thing this week. Look at your longest-lived open branch and your oldest live flag, and put a name and a date against each. Branch lifetime and flag lifetime are the two numbers that decide whether either mechanism helps you, and the two nobody is currently tracking.

Platforms consulted via public documentation and pricing pages only: LaunchDarkly, Statsig, Harness, Flipt, Dorkly, Microsoft.FeatureManagement. Not consulted hands-on: all of them. No product in this article has been installed, configured or measured by this page.