Post 16
Shipping in Slices: How I Scope a Front-End Engagement
Most projects go sideways in the first two weeks, before anyone writes real code. Here is the scoping process I use to keep a build honest — written scope, vertical slices, and a definition of done that survives contact with production.
A front-end project rarely fails because someone picked the wrong state library. It fails because the scope was a vibe, the milestones were aspirational, and nobody agreed on what “done” meant until it was already late. By the time the code is the problem, the project has usually been in trouble for weeks.
So before I write anything, I spend real effort on scoping. Here is what that looks like.
Start with the outcome, not the feature list
The first conversation is not about screens. It is about what has to be true when the work is finished. I try to get answers to four questions:
- Who is this for, specifically — a role, a job to be done, a moment in their day.
- What changes for them once it ships. What can they do that they cannot do now.
- How we will know it worked — a number, a support-ticket trend, a conversion step, a qualitative signal.
- What is explicitly out of scope for this round. This one is the most valuable and the most skipped.
If a team cannot answer the third question, that is not a reason to skip it. It is a sign that success needs defining before the build, or the project ends when everyone is tired rather than when it is done.
Write the scope down
The output of discovery is a short document — usually two pages — that says what is in, what is out, the risks I can see, and a rough sequence of milestones. It is not a contract and it is not a spec. It is a shared understanding that we can both point at later when someone says “wait, I thought this included…”
1# Reporting dashboard — v1 scope2 3## In4- Overview page: 4 KPI tiles + 1 trend chart (last 30d)5- Filter by team and date range, state lives in the URL6- CSV export of the current view7- Empty / loading / error states for every data surface8 9## Out (v1)10- Saved views / bookmarks11- Scheduled email reports12- Drill-down from a tile to a detail page13- Mobile layout below 640px (desktop-first, degrades gracefully)14 15## Risks16- Metrics API is undocumented — 1d spike to map it before estimating17- "Team" grouping not modelled in the DB yet — needs a backend decision18- Design covers the happy path only; I'll propose the empty/error states19 20## Milestones211. One KPI tile, real data, deployed, with all four states (~3d)222. Remaining tiles + trend chart + shared data layer (~4d)233. URL-driven filters + CSV export (~3d)244. Polish pass, a11y, perf budget, docs (~2d)The risks section is the part people underrate. Naming the thing that might blow up the estimate — an undocumented API, a design that is not finished, a dependency on another team — means it gets managed instead of discovered at the worst possible moment.
Slice vertically, always
The single most important structural decision is that every milestone is a vertical slice: a thin path through the whole stack that produces something real. Not “build all the components,” then “wire up all the data,” then “style everything.” That approach means you have nothing shippable until the very end, and no way to course-correct.
1Horizontal (fragile) Vertical (resilient)2 3Week 1 all components Week 1 one feature, end to end4Week 2 all data plumbing Week 2 second feature + shared plumbing5Week 3 all styling Week 3 third feature + polish pass6Week 4 integrate + pray Week 4 the long tail, main always shippableA vertical slice for a dashboard might be: one chart, with real data, on a real route, deployed to a preview URL, with a loading and an error state. It is small. It is also a complete, honest answer to “does this approach work.”
Keep pull requests reviewable
A slice still contains many PRs, and each one should be small enough that a reviewer can actually hold it in their head. If a PR is 900 lines, the review is a rubber stamp and the bugs ship. I aim for PRs that can be reviewed properly in fifteen minutes, with enough context in the description that the reviewer does not have to reverse-engineer the intent.
1## What2Adds the revenue KPI tile to the overview page.3 4## Why5First tile of milestone 2. Establishes the tile component API the6other three will reuse.7 8## Notes for the reviewer9- `<KpiTile>` takes a `query` prop, not data — it owns its own10 Suspense boundary so tiles stream independently.11- The number formatting helper is intentionally dumb for now;12 locale-aware formatting is a v1 polish-pass item.13 14## Screenshots / preview15https://pr-142.preview.acme.dev/dashboardDefine done before you need it
“Done” for a feature, in my work, means all of this — and I put it in the repo as a checklist so it is not a matter of memory:
1### Definition of done2- [ ] Happy path works on mobile and desktop3- [ ] Empty, loading, error, and slow states are designed (not defaulted)4- [ ] Keyboard reachable, focus visible, screen-reader sensible5- [ ] No new long tasks; images sized; no layout shift6- [ ] A test covers the part that would be expensive to break7- [ ] Docs / conventions updated in this PRA feature that only handles the happy path is not 80% done. It is a demo. The last 20% is most of the value and all of the trust.
Leave the team better than you found it
The refine phase is not just polish. It is writing down the conventions, the data-fetching pattern, the component API rules — so the next person can extend the work without guessing. A handover session, and then availability for the questions that come up in the two weeks after.
If I have done the job well, the code is boring to extend, production behaviour is predictable, and nobody needs to call me. That is the goal.
Found this useful? Pass it on.
Want a custom write-up for your team? Get in touch.
Building something like this?
If a post here maps to a problem on your roadmap, that's usually a good sign we should talk.