Thin Slice

Cut down to the smallest scope that can run end-to-end once, then add on top.

The goal of v1 is not to cover every feature. It's to let one real person complete one full thing once.

What you'll run into:

• Three weeks in, no single flow has made it from start to finish
• Seven or eight screens drawn, none actually usable
• The scope keeps growing, so you never dare show it to anyone

Slicing horizontally is the most natural and the most dangerous approach: finish all the UI, then all the APIs. It sounds orderly, but until everything is done, you have nothing you can validate. Three weeks without a single flow working end-to-end usually isn't slow work — it's the wrong cut: every layer seems to advance, yet no layer proves anything. Slicing vertically is the opposite — as soon as the first slice is done, someone can use it, and real feedback starts coming in. The term "vertical slice" comes from project management: the minimum amount of work across all technical layers that makes one feature actually work. vertical-slice

How to cut

Cut along one complete user task, not along technical layers.

The test for a correct cut: when this slice is done, can you find a real person to use it, and do you learn something new after they do? If the answer is no, the cut is wrong.

For an expense tracker, the first vertical slice is "log an expense": open, enter amount and category, save — this one path, end to end. It crosses the interface, logic, and storage layers, but covers only that single action. Once it's done, you can hand your phone to a friend and watch them log an entry, and see where they get stuck.

How small

The bar isn't "few features," it's "can run end-to-end once." These cuts are safe to make:

• Multiple input methods: keep one
• Edit and delete: build create only
• Filters and sorting: skip while data is sparse
• A settings page: use hardcoded defaults
• Multi-platform: build one first
• Sign-up and login: use one local account

After cutting, count again: does the first slice still have a path from start to finish? As long as it does, you can probably cut it smaller still.

What you can't cut

• The main thread's completeness can't be cut. You can drop a few entry points, but the path from start to finish has to work.
• The four states can't be cut. Empty, loading, error, normal. Your first users all hit the empty state — cutting it means cutting your first impression (see All Four States).
• Data reliability can't be cut. Fewer features is fine; lost data is not.
• The hypothesis you're validating can't be cut. The whole point of this slice is to test it — cut it and the work was for nothing.

These four aren't features; they're the preconditions for a real person to use the product at all. Lose someone's data once and that user never comes back — they're also the easiest things to defer as "later," and the cost of deferring is no one willing to use it.

A note for the AI

PROMPT · cut the first slice

I want to build: [one-sentence product description]
The hypothesis I want to validate in v1 is: [e.g. "he is willing
to spend ten seconds a day logging one entry"]

Help me cut the first slice. Requirements:
1. Cut vertically along one complete user task; do not layer by
   frontend/backend/database.
2. List the minimum number of pages and the minimum data fields
   this slice needs; cut everything cuttable.
3. Explicitly list what this version does NOT include, and why
   it isn't needed now.
4. Separately confirm these are preserved: the main flow runs
   end-to-end, all four states exist, data can't be lost, and
   key operations can be undone.
5. Estimate the effort for this slice (hours / days / weeks).
   If it exceeds a week, cut again and tell me how to make it
   smaller.

Give me the plan first; write code only after I confirm.

Line five is the key to preventing scope creep. If the AI's plan comes out as "week-scale" from the start, it has probably padded in a bunch of extras for you. Use the same habit for every feature you add later: ask whether it can be cut smaller and run end-to-end in the real environment first.