On my latest project, I was tasked with rebuilding a mobile app’s order customization workflow. This included work such as modifying the product itself and persisting that state live as well as in the cart when it was finally ready to be ordered.
The work was planned as one feature branch that could have easily turned into a large, overwhelming pull request. Instead, our team chose to divide the work into seven vertical slices, each with its own PR. Where this gets interesting is that we did not need to merge these in numerical order! This greatly impacted the speed of delivery and testing. Done without any nasty rebases, our strategy worked.
Use vertical slices instead of horizontal layers.
It’s tempting to split up work horizontally — by state, UI, API, etc. This can create a bottleneck, though, where nothing can ship until all three land. Then, you may still have to worry about integration as an extra step.
We sliced vertically — every slice had a thin, end-to-end, mergeable change to the real product. Below is a table showing our actual timeline.
The numbers are the plan; the dates are what happened. Slices 1-4 did have to be in lockstep with one another. Slices 5 and 7, however, were cut from Slice 2. They never needed 3 or 4 to finish — so these landed early. Merging out of order only works if these slices of work don’t secretly depend on each other. Three habits kept this true so we could deliver efficiently.
Create written specs per “slice” with a “sequencing note”.
Before writing any code, we wrote a short and easy-to-read (sections!) Markdown spec per slice. The most valuable section of this was the “Sequencing note”. This was a paragraph asking what the current slice assumes already exists and what to do if it does not. Slice 5’s sequencing note named its branch point (cut from Slice 2), named some broken behavior, and excluded fixing that immediately as a part of its work. This was specifically noted as Slice 3’s responsibility, not 5’s.
Call out merge conflicts beforehand, and keep a changelog.
Parallel work on a feature means two branches will eventually touch the same file. We can’t avoid that — but we can predict it. In places where this was expected to happen, we really only needed one sentence to be included in the spec: “This slice and Slice X both touch the Y page, so whichever lands second rebases”. When Slice X merged first, the previous one rebased onto it and the changelog recorded this. This gave our agent clarity — there was no need to take guesses if a collision could/would break a page. It was planned, revisited, fixed.
Leave labeled comments for the next slice.
Some slices couldn’t fully finish because their handoff target didn’t exist yet. For example, an “Add” button on one slice needed a confirmation page to route to post-click. This had not existed yet. Rather than block our agent, we shipped this feature with a clearly-commented line so that future integration would pick up on this right where we left off.