The Pace Car design integration branch

TL;DR

Two lanes. The exploration lane is a long-lived design branch called design/prototype. Designers branch off it, build real flows in code, and merge back in. The shipping lane is master, and we never merge the prototype branch into it. We cut one bounded slice at a time, port it onto a fresh master branch, and ship it as a small, reviewable PR.

Result.

Design moves at design speed.

Production stays production-safe.

Engineering never has to absorb a six-month integration dump.

The problem I was trying to solve

Most teams force a choice.

Move fast in prototypes and pay for it later in engineering chaos, or stay safe in production and slow design down to a crawl.

I had been on both sides of that tradeoff.

I did not want to keep choosing.

The trigger for Pace Car was a specific moment. I had a design integration branch with three months of design-driven work piled into it. Engineering was afraid to look at it. The longer it sat, the harder the merge became. We eventually had to spend two weeks carving it back into reviewable pieces. It worked, but it was the kind of effort nobody wanted to repeat.

So I started writing down a different approach. The first version was a one-pager. The current version is the framework below.

The two lanes

I think of the model as a race.

Master is the highway. design/prototype is the pace car.

The pace car drives ahead of the pack, tests conditions, and sets the speed.

It does not win the race.

It makes the race winnable.

The exploration lane · `design/prototype`

This is a long-lived design integration branch. It is the place where approved design work accumulates. It is also the place where production gets synced back in, regularly. The point is to keep the prototype from drifting off into a parallel universe.

What it is for:

designers branch off it, build flows in code, and merge back in when the work is real enough to evaluate
the branch is a controlled proving ground, not a dumping ground
UX gets made real enough to prove value before anyone cuts it into a production slice

Sync cadence I actually use:

merge origin/master into design/prototype at least weekly
also sync before any major slice-selection or promotion-review session
the designer owning the current pace-car lane resolves the conflicts unless an engineering-only production concern requires escalation

The shipping lane · `origin/master`

Stable, production-safe, real APIs, real contracts, engineering-owned reliability. Everything that ships to customers has to survive here.

Designer branches · pit stops

Short-lived branches off design/prototype. A designer branches from the pace car, builds a focused piece of exploration, and merges back into the design integration branch when the slice is ready for review.

Shipping branches · race-ready cars

Fresh branches off master. They get opened only after a slice is approved, and they contain only the code we intend to ship. They become PRs to production.

How it actually runs

Five operating rules. They are the difference between this working and this becoming another integration dump.

1. Explore in the pace car lane

Designers build in code, not in static isolation.

They branch from design/prototype, wire mock-backed states, test flows as real experiences, and validate the work as a product.

This is where design earns the right to ship.

2. Keep the pace car close to the highway

The design branch has to stay close enough to production to be useful.

We sync origin/master into design/prototype every week.

Production logic, contracts, safety, and data boundaries do not get replaced by design drift just because they are inconvenient.

If a prototype deviation matters, we name it and preserve it intentionally.

If it does not, it loses to production over time.

3. Cut slices, not chunks

We do not merge the design branch into production wholesale.

We take one bounded slice at a time: a single visible behavior, a coherent user-facing improvement, and a production-ready story.

If the change does not fit that shape, it is not ready to ship.

4. Rebuild every production PR from master

When a slice is approved, we do not ship from design/prototype.

We open a fresh branch from master, port only the approved files or hunks, verify them, and review the result as a clean production artifact.

The prototype branch is where we learn.

Master is where we commit.

5. Use separate worktrees for discovery and shipping

Lane separation should be physical, not just conceptual.

I keep two persistent worktrees open: ~/Desktop/design-prototype for the prototype and discovery lane, and ~/Projects/shipping for shipping and the production port.

The prototype worktree is where design integration, experimentation, and slice selection happen.

The shipping worktree is where production branches are created from origin/master and where approved slices are rebuilt for PRs.

Keeping them separate keeps the shipping lane clean even when the prototype lane is intentionally messy.

How a slice actually ships

The sequence I run every time:

Identify a candidate slice in design/prototype.
Run a Promotion Audit on it.
Review the candidates with the team.
After approval, switch to ~/Projects/shipping.
Branch from fresh origin/master.
Manually port only the approved slice.
Start a local server to verify the port and refine.
Open a draft PR to review and fix CI issues.
Open the PR only after team approval.

Shipping worktree rules

Never stage production-port work from the prototype worktree.
Never clean, reset, or stash the prototype worktree to make shipping easier.
Always start the shipping branch from fresh origin/master.
If ~/Projects/shipping is dirty, stop and fix the environment first.

Who owns what

Slicing is joint work, but the responsibilities are different.

The designer defines the slice scope, the intended user-visible outcome, and what to exclude.
The assigned engineer performs the production re-cut onto a fresh master branch.
Both review the Promotion Audit before implementation begins.
Engineering owns the final production-safe adaptation work required for shipping.

This keeps design responsible for product intent and engineering responsible for release correctness.

Porting default

Manual extraction is the default.

I use cherry-pick only when the source commit is already narrow, self-contained, and production-safe.

In practice, most prototype commits are too mixed to trust as direct shipping artifacts.

The burden of proof is on the cherry-pick, not on the manual port.

What it gave us

Between March and June 2026, six designers pushed 139 PRs into design/prototype. Manager, PM, and research partners added seven more. The cross-functional team worked in code, not just mockups.

Result: 146 PRs to the design branch, 130 of them merged. The pace-car lane made the work visible, reviewable, and cheap to throw away when it needed to change. Production PRs stayed under a few hundred lines. They shipped in single-digit days from approval.

Rules of engagement

These are non-negotiable.

Branch from the pace car, ship from the highway.
Design work starts from design/prototype.
Production work ships from a fresh branch off master.
Never confuse the proving ground with the release lane.
The pace car is allowed to explore, not to drift.
The integration branch exists to make UX real, not to become a permanent fork of the app.
We preserve intentional UX. We do not preserve accidental entropy.
Production behavior wins by default.

On shared surfaces:

contracts win from prod
safety wins from prod
routing wins from prod
accessibility wins from prod
telemetry wins from prod

What this is not

It is not a staging branch that eventually gets merged wholesale.

It is not a prototype fork with no return path.

It is not designers pushing random code straight to production, and it is not engineering acting as cleanup for unresolved design exploration.

It is a working system for converting design momentum into production value without one team or the other absorbing the cost.

What makes a good slice

A good production slice is visible, bounded, coherent, testable, reviewable, easy to explain, and easy to port onto master.

If a change is too broad, too coupled, or too dependent on unrelated branch state, it is not a slice.

It is unfinished inventory sitting in the pace car.

The short version

The pace car does not win the race.