Feature Flags or Release Branches: What a Team of Five Should Actually Run

The same sources that explain both approaches—sources—agree on this much: flags decouple deploy from release, while branches decouple complete features from the shared trunk until someone decides to ship.

That choice sounds architectural. It is actually budgetary. Every mechanism for hiding work charges rent.

Hidden Work, Two Ways

Feature branching in Git creates separate lines of development for each feature, as described. Developers work in isolation, merge when finished, and the repository history records that isolation. Feature flags take the opposite path: new code lives on the main branch, shielded from execution by a conditional. The flag turns it on or off without another deployment.

Documentation, emphasizes that trunk-based development with feature flags keeps the trunk releasable at every commit. The release becomes a separate, controlled decision. Harness puts this more sharply: flags let incomplete work merge frequently while staying unreleased.

Release branches serve the same purpose through structure rather than conditionals. DevOps.com's 2017 analysis notes that some workflows gather completed work onto a release branch to cut a releasable version, rather than shipping directly from the shared trunk. The advantage, as the same source notes, is that unfinished work can remain in a shared branch without blocking release of completed work. Statsig's 2024 perspective adds a practical boundary: feature branches work best for smaller teams focusing on isolated features.

Both approaches solve the same problem. Neither is free.

What Each Approach Charges

The sources name specific costs for flags. Best-practices guides cite three: long-lived dormant code paths, flag-management overhead, and the need to remove flags after launch. These are not edge cases. They are the ongoing tax of a conditional system.

A flag adds state to every execution path it touches. The combinatorial test burden grows with each new flag—now you must verify behavior when the flag is on, off, or toggling. Dead code accumulates when flags outlive their purpose. The management overhead includes tracking which flags exist, who owns them, and whether they are still needed.

Release branches charge differently. Merge conflicts accumulate as branches diverge. The longer a branch lives, the more its rebase or merge costs. The team must maintain multiple live lines of code. Neither source in the brief explicitly frames these as "merge-conflict time" or "rebase time," but the DevOps.com analysis describes the isolation that creates them. The cost is real, just differently distributed.

The Four Flag Types

Not all flags serve the same purpose, and treating them interchangeably creates operational risk. A best-practices post separates flags into four categories: release flags, experiment flags, operational flags, and permissioning flags.

Release flags are short-lived. They exist to shield a feature until it is fully rolled out, then they should be deleted. Experiment flags live only as long as the A/B test they support. Operational flags can be longer-lived; they control system behavior like circuit breakers or rate limits. Permissioning flags can persist for years, governing access by user role or subscription tier.

Guidance confirms this taxonomy and adds practical detail: a single flag can expose a feature to employees or an allowlist, ramp it to a percentage of users, stop it during an incident, or compare variants without another deployment. But these capabilities belong to different flag lifecycles. A release flag pressed into long-term permissioning duty becomes unmaintainable technical debt. An operational flag treated as temporary risks feature removal during incident response.

The five-person team must know which type it is creating. The cleanup discipline differs.

The Rule That Prevents Rot

The sources converge on a specific discipline. Guides both advise: record an owner and an expected removal or review date when a flag is created. DesignRevision sharpens this for release flags specifically—remove them within 30 days of reaching 100% rollout.

This is not optional hygiene. It is the mechanism that prevents flag proliferation from overwhelming a small team. Without an owner, no one answers for cleanup. Without a removal date, the flag becomes permanent by default. The 30-day rule for release flags creates a hard boundary: either the feature is stable enough to become the default path, or it was not ready for rollout.

Flags do not eliminate the work of release. They relocate it into maintenance windows. The team that cannot commit to these windows has not bought flexibility. It has bought debt.

What a Small Team Can Actually Test

Flags enable specific release tactics that branches cannot replicate without heavy automation. Guidance notes that feature flags support canary deployments and A/B testing in the release phase. Growthbook lists the practical controls: employee-only exposure, percentage ramp, emergency stop, and variant comparison.

These capabilities matter for a small team with limited QA resources. A branch-based release requires a decision: ship or don't. A flag-based release allows graduated exposure. The incomplete feature can reach production code paths without reaching production users. The experiment can run against live traffic without maintaining separate infrastructure.

But each capability adds paths to test. The team that enables percentage rollout must verify behavior at 0%, 1%, 50%, and 100% exposure. The team that supports emergency stop must test the stop path. The flexibility is real. The testing burden is equally real.

When a Release Branch Still Earns Its Keep

Flags do not cover every case. DevOps.com's 2017 analysis preserves the branch option for workflows that require version gathering. The two exceptions that survive scrutiny in the sources: shipped clients that users choose when to update, and regulated releases that must be reproducible.

A mobile application distributed through app stores cannot recall a binary. The release branch becomes the point of record for what shipped. A regulated environment—financial services, healthcare, safety-critical systems—may require reproducible builds with documented contents. The branch provides that audit trail.

Statsig's 2024 perspective on small teams and isolated features suggests this is not failure. It is fit. The team of five running a web service with continuous deployment has different constraints than the team shipping packaged software or operating under compliance requirements.

The cost accounting differs too. A release branch for a shipped client pays for itself in version control. A release branch for a continuously deployed web service duplicates work already handled by flag-based trunk development.

The Cleanup Rule as Decision Test

If your five-person team cannot name the flag type, owner, and removal date for every live flag, you have not implemented feature flags. You have implemented feature debt. The 30-day cleanup rule for release flags is not a guideline. It is the proof that you meant what you said about decoupling deploy from release.

Release branches survive where the product requires them—shipped clients, regulated releases, teams whose features are genuinely isolated and short-lived. Elsewhere, trunk-based development with disciplined flag management buys more control for less ongoing overhead. The choice is not philosophical. It is the count of how many hidden-work mechanisms your team can actually maintain, and whether the one you chose charges rent you can afford.