Feature Flags: How to Merge Daily Without Shipping Half-Built Work

The argument for a long-lived feature branch goes: the work takes three weeks, it cannot ship half-done, so it lives on a branch until it is ready. The cost shows up at the end - a three-week merge, conflicts with everything that moved underneath, and a review nobody can hold in their head.

Feature flags attack the premise instead of the branch. If unfinished code can sit in production safely, invisible behind a flag, there is no reason to keep it out of main.

What a feature flag is#

A flag is a runtime check around new behaviour:

if (feature('new-billing-dashboard')) {
    return view('billing.dashboard-new');
}
return view('billing.dashboard');

Laravel teams have good options for the feature() part: Laravel Pennant (first-party, ships with recent Laravel versions), a config value, or an external service. The mechanism matters less than the habit: new behaviour ships dark, off by default, and turns on when it is ready - per user, per team, or for everyone.

Why it pairs with trunk-based development#

Trunk-based development asks for small, frequent merges into main. The objection is always “but my feature is not done.” Flags answer it: merge the first slice behind a flag on Monday, the second on Wednesday, the third next week. Each merge is small, reviewed quickly, and deployed continuously - while users see nothing until you flip the flag.

The bonus nobody expects: rolling out to 5% of users, then 50%, then everyone is free. And if something breaks, “roll back” is turning the flag off - no revert deploy, no drama, exactly the cheap-exit thinking in rollback or roll forward.

The disciplines that keep flags healthy#

Name flags for the feature, not the date. new-billing-dashboard is clear in six months; experiment-2026-10 is not.

Flag the smallest unit of behaviour. One flag around one feature. A flag that controls three unrelated things cannot be turned off cleanly when one of them misbehaves.

Delete flags when the rollout finishes. A flag that stays at 100% forever is an if statement with extra steps. Make “remove the flag” the last task on the feature ticket, and grep for stale flags every quarter. This is the unglamorous part, and the part that decides whether flags stay a tool or become sediment.

Start with one flag on your next multi-day feature. The first time you merge on day one instead of week three - and turn the thing off from your phone when it misbehaves - the branch-everything habit loses its grip.