Thin-Slice MVPs

Also known as: vertical slices, incremental milestones, walking skeleton

Each session ships one small, working vertical slice (MVP1 → MVP2 → MVP3).

TrackBuilding with coding agents FamilyBuild loop Maturity Emerging ChangesDecision

Problem

Coding agents can generate a lot of code quickly, which makes it tempting to ask for the whole application at once. The result is a large, half-working codebase: many features started, few finished, no way to tell which parts work, and a review nobody can complete. Fixing it often takes longer than building it in steps would have.

Agents can produce more code than a person can review in one sitting.
Working software gives far better feedback than plans or partial features.
Small slices feel slower at first.
Some foundations, like the data model, are costly to change later.

Solution

Plan the work as a sequence of thin vertical slices, each one usable end to end: MVP1 does the smallest useful thing, MVP2 adds the next most valuable capability, and so on. Each slice gets its own spec, branch and PR, sized so one session can build, test and review it. A slice is done only when it runs, passes its acceptance tests and has been tried by a person. Learnings from each slice shape the next slice’s spec, and lasting decisions go into the Project Memory File.

Diagram

Every slice works end to end before the next begins. Feedback from using each slice changes what goes into the next one.

When to use

Use it when

Building a new app or feature with a coding agent
Requirements are likely to change once people use the software
You want reviewable PRs instead of one giant change
Several sessions or developers will contribute over time

Avoid it when

Tiny tasks that are already one slice
Fixed, well-understood specs where the whole design is settled
When slices would be so thin they ship nothing a person can use

Trade-offs

Latency

First usable version sooner; total time similar or less

Cost

Less rework from building the wrong thing

Complexity

Planning slices and keeping each one shippable

Reliability

Each slice tested and used before building on it

Gains

Working software early, and at every step after
Reviews small enough to do properly
Real feedback steers what gets built next

Costs

Some rework when early slices need restructuring
Discipline to stop adding features to the current slice
Foundations need some upfront thought despite the small steps

Worked example

Scenario
Linkwatch is built in three slices over two weeks, one spec and one PR each.

MVP1 · 1 sessionAdd URLs from a config file, run an hourly check, write failures to a log file. 8 acceptance tests. The developer runs it against 20 real URLs for two days.
LearningTwo sites block the checker’s default user agent, and alerts in a log file get missed. Both go into the next spec.
MVP2 · 2 sessionsAdds Slack alerts behind a notifier interface, a custom user agent and a retry. 12 more tests. Shipped as one PR of about 400 lines.
MVP3 · 2 sessionsAdds a small web page to manage URLs and view history. The data model from MVP1 holds up because “check results are append-only” was decided early.
ComparisonAn earlier attempt asked the agent for everything at once. It produced 3,000 lines in one go, and the developer abandoned it after a day of debugging.

Failure modes

Failure	Symptom	Mitigation
Slice creep	Current slice keeps growing with "just one more" feature	New ideas go into the next slice's spec, not this one
Horizontal slices	"MVP1: database layer" ships nothing anyone can use	Every slice is usable end to end, even if minimal
Skipping the try-it step	Slices pass tests but nobody actually used them	A person uses each slice before the next spec is written
Painted into a corner	An early shortcut forces a rewrite later	Decide key foundations (data model, interfaces) in MVP1 and record them