Every team that ships software has to answer one question: where does unfinished work live? For most of the industry's history the answer was a branch. You cut feature/new-checkout, work on it for two weeks, open a giant pull request, merge, and release. The alternative that has been quietly winning for a decade is to merge unfinished work into main continuously and hide it behind a feature toggle until it is ready.
Both approaches solve the same problem. They just put the risk in very different places, and that difference is worth understanding before your next big feature, not during its post-mortem.
What each approach actually does
A feature branch isolates unfinished work in version control. The code does not exist in main until the day you merge it, which means it cannot break production, and also means nothing about it is being tested against reality. Isolation is the feature and the bug.
A feature flag isolates unfinished work at runtime. The code merges into main early, deploys to production with everything else, and simply does not execute for anyone until the flag turns on. The deploy happens on your schedule; the release happens on the flag's schedule. Those become two separate decisions, which is the entire point of a feature flags platform.
Where branches hurt
The merge gets worse every day
A branch is a bet that main will not move much while you work. Main always moves. After two weeks, your branch and main have diverged in exactly the files you both touched, and someone spends an afternoon resolving conflicts by guessing what the other author meant. Research on trunk based development keeps finding the same thing: integration pain grows with the age of the branch, not the size of the feature.
Review quality collapses at scale
A 3,000-line pull request does not get reviewed; it gets skimmed and approved. Small, frequent merges behind a flag keep every review at a size where a human can actually hold it in their head. Your reviewers stop rubber-stamping because they are no longer asked to do the impossible.
Release day becomes an event
When the merge and the release are the same moment, that moment carries all the risk at once: new code, full traffic, no gradient in between. If something breaks, the rollback is a revert commit and a redeploy, which on most teams is a 30 to 45 minute round trip while customers are affected. With a flag, recovery is a kill switch flip measured in seconds.
Where flags hurt
Honesty helps here, because flags are not free either.
- Flag debt is real. A flag that shipped and never got removed is dead code with a conditional around it. You need a cleanup habit: name flags consistently, record an owner, and delete them once they hit 100%.
- Two code paths exist at once. While a flag is live, both the old and new behaviour must work. That is extra testing surface. It is also exactly what makes the gradual rollout safe, so the cost buys you something.
- You need somewhere to manage them. A YAML file of booleans redeployed on every change is just a slower branch. Flags pay off when flipping one is instant and visible to the whole team, which is the job of feature flag tools rather than a config file.
The comparison that matters
| Feature branch | Feature flag | |
|---|---|---|
| Unfinished work lives | In version control, unintegrated | In production, unexecuted |
| Integration pain | Grows with branch age | Continuous and small |
| Release granularity | All or nothing at merge | 1% to 100%, per cohort |
| Rollback | Revert + redeploy, ~30 to 45 min | Flag off, seconds |
| Who can release | Whoever can deploy | Anyone allowed to flip the flag |
| Ongoing cost | Merge conflicts, stale reviews | Flag cleanup discipline |
When a branch is still the right call
Flags do not replace branches for everything, and pretending otherwise is how you end up flagging a database migration and regretting it.
- Short-lived work. A branch that merges within a day or two has none of the divergence problems. Keep using them; that is just normal code review.
- Schema and infrastructure changes. A flag can gate the code that reads a new column, but the migration itself needs an expand-and-contract plan, not a toggle.
- Genuinely secret work. If the code itself must stay out of the repo history that contractors can see, isolation in version control is the tool.
The realistic answer for most teams is both: short branches for review, flags for release. The branch stops being a place where work hides for weeks; it becomes a code-review vehicle that merges behind a flag within a day.
What changes when you flip the model
Teams that move release control onto flags describe the same sequence. First, merges get small and boring. Then the release calendar stops mattering, because shipping to production no longer means showing anything to users. Then someone flips a flag to 5% on a Tuesday afternoon, watches the dashboards move, and realizes the scary part of releasing is simply gone. A gradual rollout gives you a dial where you used to have a cliff.
The last piece is measurement. Once traffic is split between old and new anyway, attaching a metric turns the rollout into an experiment, which is the subject of A/B testing with feature flags. You stop arguing about whether the feature helped and start reading the answer.
Getting started without a migration project
You do not need to convert your whole codebase. Pick the next risky feature, wrap its entry point in one flag, and merge to main as you go. Ship it dark, turn it on for the team, then walk it up the percentages. One feature is enough to feel the difference between deploying and releasing.
That is the workflow Toggled is built around: unlimited flags, targeting, one-slider rollouts and a kill switch, at flat team pricing with unlimited seats. It is in early access now; the how it works page shows the whole lifecycle in five steps, and the live console on the homepage lets you try the toggle before you ever sign up.