The merge queue problem
Long-lived feature branches solve one problem — isolating in-progress work — while creating several others.
The longer a branch lives, the further it diverges from trunk. Merge conflicts accumulate. CI pipelines that passed on day one fail on day fourteen because other changes landed in the meantime. The merge itself becomes a multi-hour event that blocks the team.
In a team of four engineers, three long-lived branches means three parallel universes of state that must eventually be reconciled. The reconciliation cost grows non-linearly with branch age and team size.
Trunk-based development + feature flags
The alternative is to ship incomplete features to production — disabled by default.
// Code ships on day 1. Flag is off for everyone.
const { enabled } = useFeatureFlag('new-recommendations');
if (enabled) {
return <NewRecommendations userId={userId} />;
}
return <LegacyRecommendations userId={userId} />;The branch is short-lived — merged to trunk within a day or two. CI passes continuously. The feature becomes a runtime concern, not a source-control concern.
What this changes
Integration is continuous. Every engineer merges to trunk daily. Conflicts are small and caught early. There is no "integration week" at the end of a sprint.
Deployment is decoupled from release. Deploying the code and releasing the feature are separate events. You can deploy on Monday and release on Thursday, after QA signs off in production.
Rollback is instant. If something breaks after activation, you toggle the flag off. No git revert, no cherry-pick, no redeploy. The fix takes effect in under 50ms.
Testing happens in production. Your staging environment does not have production traffic, production data, or production infrastructure load. With feature flags, you can test in production by enabling a flag for internal users only before any external exposure.
The feature flag as a contract
A feature flag is not just an on/off switch. It is a contract between the team shipping the feature and the team managing the release.
That contract defines:
- Who the flag targets (all users, specific segments, a rollout percentage)
- What the default value is (should always be the safe, existing behaviour)
- When the flag will be cleaned up (part of the feature's acceptance criteria)
Making this contract explicit — through a management UI, an audit log, and defined lifecycle states — is what separates a feature flag platform from a config file.
The hidden cost of flag-less deployments
Teams that do not use feature flags often underestimate the cost of their current approach because it is distributed invisibly:
- Engineering hours spent on merge conflicts
- Incidents caused by untested combinations of in-flight changes
- Slow release cycles because QA can only test complete features
- Rollbacks that require a redeploy and a 10-minute pipeline
Feature flags do not eliminate this complexity. They move it to a layer where it can be controlled, observed, and acted on faster.
When NOT to use a feature flag
Feature flags are not free. Every flag adds a branch to your application logic and a mental model overhead.
Do not flag:
- Infrastructure changes with no user-visible effect
- Bug fixes that should be deployed immediately
- Configuration that belongs in environment variables
Flag:
- New user-facing features that need controlled rollout
- Performance experiments you want to measure with a control group
- High-risk refactors where you want a fast rollback option
The discipline is knowing which is which.