Trunk-based development is one of those practices that engineers either swear by or quietly abandon after a painful trial run. The idea is straightforward: everyone commits to a single shared branch (the trunk or main) frequently, ideally at least once a day. No long-lived feature branches. No six-week integration wars. Just a continuously integrated codebase that's always close to deployable. In theory, it's the fastest path from commit to production. In practice, Australian dev teams keep trying it and drifting back to their feature branches within a few months. Here's what's actually going wrong.
What trunk-based development actually requires
The model sounds simple. It isn't. Committing directly to main every day means the build must pass, tests must be fast, and incomplete work must be safely hidden behind feature flags until it's ready. Pull these three threads away and trunk-based development becomes a liability, not an asset.
The test suite is the most underestimated requirement. If your full suite takes 45 minutes to run, no one waits for it before merging. They'll merge anyway, something breaks, and the trunk is red. Once the trunk is red regularly, the mental model collapses. Engineers stop trusting it. They create a short-lived branch "just for this ticket" to avoid the noise. That branch lasts three weeks.
Speed matters more than coverage percentage here. A 90-second suite that tests the critical paths beats a 40-minute suite that misses nothing. Most teams invest heavily in the second and get none of the first.
The feature-flag dependency teams underestimate
Trunk-based development without feature flags means shipping incomplete features to production, or holding releases until everything is done. Neither is acceptable at scale. Feature flags solve this, but they carry their own costs that catch teams off-guard.
Flags need discipline. A codebase with 200 stale flags from the past two years isn't cleaner than one with long-lived branches. It's worse, because the dead code is invisible and conditionally executed. Teams that adopt trunk-based development without a flag lifecycle policy just trade one form of mess for another.
Flag management also adds cognitive load during code review. Reviewers need to reason about which flags are active in which environments, what the cleanup plan is, and whether the flag interacts with existing ones. That's real overhead. Teams that don't budget for it find reviews slowing down, and the time savings from avoiding merge conflicts evaporate.
Why teams abandon it: the common failure patterns
Three patterns account for the majority of trunk-based development reversals.
The first is a CI pipeline that wasn't ready. Teams adopt the branching model before fixing the infrastructure. Builds are slow, flaky tests fire false alarms daily, and no one has ownership over pipeline health. The trunk becomes unreliable in weeks.
The second is external review gates. Some organisations, particularly those in regulated sectors or government-adjacent contracts, have approval workflows that assume a pull request exists before any code moves toward production. Trunk-based development technically still supports short-lived branches for review (some teams use branches that live less than 24 hours), but fitting that into a 5-day change advisory board cycle is genuinely difficult. The process wins. The branching strategy loses.
The third is team size and structure. Trunk-based development scales well when everyone shares context on the codebase. It gets harder when 40 engineers across 6 time zones are committing to the same files. Without very tight module boundaries and ownership conventions, you get conflicts and coordination overhead that feature branches were designed to prevent. The model is more suited to smaller, high-trust teams or codebases with strong separation of concerns.
How to tell if your team is actually ready
Four honest questions to ask before switching.
- Does your test suite run end-to-end in under 10 minutes? If not, fix that first.
- Do you have a feature flag platform (LaunchDarkly, Unleash, AWS AppConfig, or equivalent) already integrated into your stack?
- Can a broken build block deployment automatically, without anyone having to notice and manually intervene?
- Does your team commit at least daily right now, even on feature branches? If commits are rare, the habit isn't there yet.
If three or four answers are no, trunk-based development will fail for structural reasons, not because the model is wrong. Fixing the infrastructure first and then adopting the branching model gives a much higher success rate than doing it the other way around.
What works when full trunk-based development isn't feasible
Short-lived feature branches with a hard time limit (24 to 48 hours maximum) capture most of the integration benefits without requiring full infrastructure readiness. The discipline of merging before the branch ages forces smaller commits and earlier integration, which is the thing that actually matters.
Some teams run a hybrid: trunk-based for backend services with stable APIs and short-lived branches for UI work that needs designer review before integration. That's not a purity violation. It's an honest acknowledgement that different parts of the codebase have different review requirements.
The goal is reducing the time between when code is written and when it's integrated. Trunk-based development is one way to get there. It isn't the only way. A team that merges every 48 hours on well-scoped branches ships far better than a team that adopted trunk-based development but is running a red build three days a week.
The pattern that actually kills velocity isn't the branching model. It's branches that live for weeks because the ticket was too large, the tests were too slow, or no one had the time to review. Fix those, and the branching strategy almost doesn't matter.