What to Build First
Dependency, risk, user value and learning value — four questions asked of each piece, and the first vertical slice falls out. One possible sequence for the store, and the other sequences that are also right, and when.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
The decomposition is done and everything is on the list. Which piece is first, which is second, and what makes an order defensible rather than habitual?
You have the store broken into nine pieces and an estimate with ranges. You open the editor to start, and realise the list is a set, not a sequence. Products first seems obvious. So does payment, after the last lesson. So does deployment, since nothing counts until it is live. You start with whichever file is open.
Build in the order the pieces appear in your head, which is usually the order a user meets them: products, then cart, then checkout, then payment. It is a defensible-sounding order, it matches the workflow, and it needs no further thought — which is why it is a reflex rather than a decision.
The user-journey order puts payment — the riskiest piece — last, and deployment — a prerequisite for testing payment — after that. The order was chosen by narrative, and the narrative has the surprises at the end.
- The user-journey order puts payment — the riskiest piece — last, and deployment — a prerequisite for testing payment — after that. The order was chosen by narrative, and the narrative has the surprises at the end.
- It also puts nothing testable end to end until late. Products, then cart, then checkout: three pieces built before a single order exists to look at, so the first evidence that the decomposition was right arrives after most of the work.
- When a stakeholder asks "why are you doing the cart before deployment?", there is no answer except "that is the order". An order with no reasons cannot be revised when circumstances change; it can only be abandoned.
- Whichever file was open when you started becomes the first piece, and the first piece shapes everything after it. An accidental order is an order all the same; it just has nobody's judgment in it.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Ask four questions of every piece, and write the answers next to it. *Dependency*: what has to exist before this can? *Risk*: how much would the rest change if this went unexpectedly? *User value*: how much closer does this bring a customer to completing the core workflow? *Learning value*: what would building this teach that nothing else would?
- Let dependency gate and the other three decide. Nothing can come before its prerequisites; among the pieces that are unblocked, the one with the best combination of risk, value and learning goes next. Which of those three weighs most is a judgment about *this* project — the labs make it a slider for a reason (Trade-Off Thinking).
- Make the first item a vertical slice rather than a piece: the thinnest path through every layer the store needs, so that the environment is proven and every later piece lands into something that already runs (The Walking Skeleton).
- Write the order down with its reasons, and write down the alternative you rejected and when you would choose it instead. An order is a sequence of decisions, and the reasons are what make it revisable when the payment spike changes a dependency.
Four questions, every piece
The reflex knows the pieces in narrative order. The move scores them. The matrix below is deliberately coarse — low, medium, high — because the point is to see which pieces compete for the first slot, not to compute a winner to two decimal places. Read the dependency column first: it removes most of the choices.
| Piece | Depends on | Risk | User value | Learning value |
|---|---|---|---|---|
| Product model | — | Low | Medium (everything needs it) | High (proves the environment) |
| Display products | Product model | Low | Medium (first visible thing) | Low |
| Cart | Products | Low–medium (persistence decision) | Medium | Low |
| Checkout without payment | Cart | Medium | High (an order exists) | Medium |
| Order persistence and history | Checkout | Low | Medium | Low |
| Payment | Order; public URL | High (spiked; shape now known) | High (it is a store) | High |
| Failure handling | Payment | Medium | Medium (invisible until it is not) | High |
| Admin | — | Low | Low for customers, high for the founder | Low |
One possible sequence — and the other one
The order below is the one the four questions produce for a store whose payment piece was already spiked. It reaches a working store without payment by the fourth step, which is the earliest point at which a real person can be watched using it, and it builds payment onto an order that already exists.
The alternative is not a footnote. It is a different, valid order for a different situation, and a team should be able to say which situation it is in.
- 1Product model
because No dependencies, everything needs it, and as the first slice it proves the database, the server and the page connect.
- 2Display products
because The first thing a customer can see; cheap, low-risk, and makes every later step visible.
- 3Cart
because Checkout cannot exist without it, and building it forces the anonymous-vs-account decision early, where changing it is cheap.
- 4Checkout without payment
because An order now exists. The core workflow is testable end to end with a real person before the external provider is involved.
- 5Order persistence and history
because Payment needs an order to confirm, and the customer needs to see what they ordered.
- 6Payment
because Risk was already reduced by the spike; now that an order and a public URL exist, the integration lands onto something that works.
- 7Failure handling
because Timeouts, duplicate confirmations and sold-out-at-checkout can now be injected against a working path rather than imagined.
- 8Admin
because Nothing downstream depends on it and the founder can insert products by hand until it exists; last, with its cost visible.
The first slice, and what grows from it
The first item in any order this move produces is a slice, not a layer. It is the product model *through* an endpoint *through* a page, because a model on its own proves nothing about the environment. What it does not prove is longer than what it does, which is what makes it a first step rather than a milestone.
- DatabaseOne products table with one row inserted by hand.
- APIGET /products returns that row as JSON.
- PageRenders the name and price from the response.
Among unblocked pieces, what decides?
when A piece with many dependents is poorly understood by everyone on the team.
cost Visible value arrives later, and the spike may answer a question that turns out to be simple.
when The risky pieces are known shapes, and early real use will find requirements no spike would.
cost A late surprise in a piece that was assumed known has nowhere to go but the deadline.
when The goal is understanding — a solo learner, a research prototype — rather than a launch.
cost The sequence may never reach a usable product, which is fine only if that was the goal.
How to do it
Most important first.
- Draw the dependencies before ranking anything. Products before cart, cart before checkout, order before payment confirmation, a public environment before webhooks — the graph removes most of the choices before judgment is needed (Dependency First).
- Among unblocked pieces, name the one whose bad answer would change the most others and put it, or a spike of it, early (Risk-First Development).
- Then name the one that first lets a customer complete something. A store where an order can be created without payment is a store you can watch someone use; pull that forward (Value First).
- Score learning value honestly: building the cart teaches nothing new to someone who has built carts; building the confirmation handler teaches the provider's real behaviour. Learning value is highest where the estimate range is widest.
- Choose the first slice to be small and to cross every layer, then let the chosen order dictate what grows from it (Implementation Order).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The store, scored: product model (no dependencies, low risk, medium value — everything needs it, high learning about the environment); display products (depends on model; low risk; first visible value); cart (depends on products; low risk; needed for checkout); checkout without payment (depends on cart; medium risk; high value — an order exists); order persistence (depends on checkout; low risk); payment (depends on order and a public URL; high risk; high value); failure handling (depends on payment's answer); admin (no dependencies; low risk; low customer value, high founder value).
- One possible sequence falls out: product model → display products → cart → checkout without payment → order persistence → payment → failure handling → admin. Dependencies fix most of it; the judgment is in placing payment after an order exists (so there is something to mark paid) and admin last (nothing downstream needs it, and the founder can insert products by hand until then).
- The rejected alternative, written next to it: spike payment before anything, then the same sequence. Chosen when the provider is unknown to everyone on the team, because its answer could reshape checkout. Here the spike already happened in the previous lesson, so payment can wait for its prerequisites.
- The chat app, same four questions: the data model for users, conversations and messages has no dependencies and everything needs it; sending a message is the first value; realtime delivery has high learning value; read state across devices has the highest risk because its answer changes the model. Order: model → send and list messages → read state spike → realtime → read state proper. Different project, same questions, different sequence.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Every piece in the order has a reason next to it, and the reason is one of the four questions rather than "it came next".
- The first item is a slice that runs end to end, and each later piece is added to a working system rather than to a pile.
- An alternative order exists in writing, with the condition under which you would switch to it.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What has to exist before this piece can, and what does the dependency graph already fix about the order?
- ?Among the pieces I could start now, which one's bad answer would change the most others?
- ?Which piece first lets a user complete something end to end, and how far away is it?
- ?What would building this piece teach me that nothing else on the list would?
- ?What is the alternative order I am rejecting, and under what condition would I switch to it?
What can go wrong
- Scoring becomes a spreadsheet with weights to two decimal places, and the order is whatever the arithmetic produced. The four questions are prompts for judgment; the numbers are how the judgment is written down, not where it comes from.
- Dependency is over-applied as "foundations first": the entire data model, then all the endpoints, then the UI. That is horizontal layering with a dependency argument attached, and it has the same failure — nothing testable until the end (The Horizontal Layers Trap).
- The order is decided once and never revisited. The payment spike finds that confirmations need a public URL; deployment stays at the end because the list was already made.
- The move is applied to a three-piece task where the order is obvious. Asking four questions of "add a field, show it, save it" is ceremony; the move earns its cost when pieces compete for the first slot.
- An order with reasons takes an hour to produce and invites argument about each reason; an order by habit takes a second and invites argument only when it fails.
- Putting admin last means the founder edits the database by hand for weeks — a real cost, chosen, and better than the same cost unchosen.
- "This is the right order for a store." It is one possible sequence, and the device says so in its data. A team that has integrated the provider five times, or a founder who needs a demo of the catalog next week, gets a different order from the same four questions.
- "Dependency order is the order." Dependency gates; it does not rank. Products and admin both have no dependencies, and the reason products go first is value and learning, not the graph. "Build the foundations first" is falsifiable: made precise, it says "build everything with no dependents before anything with dependents", and that produces horizontal layers.
- "The first slice should be the most valuable feature." The first slice should be the thinnest thing that crosses every layer, because its job is to prove the environment. The most valuable feature is what the order builds *toward*, usually by the fourth or fifth item.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALDependency, risk, user value and learning value are questions any piece of any decomposition can be asked; the weighting between them is what changes — a research prototype weights learning, a launch weights value, an unfamiliar integration weights risk.
- TEAM-SPECIFICFor a solo learner the order should maximise learning and early feedback, so a thin slice goes first and risk goes second; for a team under a launch deadline with the provider already known, value dominates and the sequence pulls checkout forward and pushes anything with no customer-facing output to the end.
- ILLUSTRATIVEThe store's nine pieces, their scores and the two sequences are invented to show the four questions producing an order; a real project's scores come from its own decomposition and its own team.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The capstone at /thinking/capstone walks the store through ten stages in an order close to this one — and asks at each stage why that order and not another.