Implementation Order
Product model → display products → cart → checkout without payment → order persistence → payment → failure handling → admin: one defensible sequence for the store, with the reason for each step. Not the only sequence — and the device says so.
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 store is decomposed into pieces and you can build any of them. Which do you build first, in what order, and how would you defend the order to someone who would have chosen differently?
You have the decomposition: catalog, cart, checkout, orders, payments, admin. You also have a nagging sense that it does not matter which one you start with because they all have to exist anyway — so you started with the one you found most interesting, which was the admin panel, and three days later nothing a customer could use exists.
Start with whatever is clearest. Admin is CRUD, you know CRUD, and getting something finished feels better than staring at checkout. Order is a detail; the total work is the same either way.
The total work is not the same either way, because the order decides what is learned when. Admin first taught nothing about the store — every store has an admin — while checkout first would have surfaced the price-snapshot question, the empty-cart case and the payment unknown in the first week.
- The total work is not the same either way, because the order decides what is learned when. Admin first taught nothing about the store — every store has an admin — while checkout first would have surfaced the price-snapshot question, the empty-cart case and the payment unknown in the first week.
- Three days in, nothing runs end to end, so nothing can be shown, tested against a real workflow or measured. The admin panel creates products that nothing displays; it is a component awaiting a system.
- The hardest piece — payment — is still at the end, where it was implicitly placed by starting with the easiest. It will arrive on the critical path with the least time left and the least room to change the design if the provider forces a different shape.
- Nobody can say what the store will do at any given date, because the sequence was chosen by interest rather than by what each step enables. "When can a customer place an order?" has no answer.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Order the pieces by three questions asked of each: what does this require to exist first (dependency), what does building it teach or de-risk (risk), and what can a user do once it exists that they could not before (value). A sequence that can answer all three for every step is defensible; one that cannot was chosen by something else (What to Build First).
- Reach a working system as early as the dependencies allow, then extend it. For the store that means a customer can complete something end to end — even an order with no payment — before any piece is polished. "Working" is the precondition for every later step being a loop rather than a part (Iterative Development).
- Pull the riskiest unknown forward to the point where it is no longer blocked by dependencies, and no further. Payment cannot be integrated before an order exists, but it can be researched on day one; the spike is not gated, only the integration is (Risk-First Development).
- Write the sequence down with the reason beside each step, and write down one alternative sequence and when it would be better. A sequence without reasons cannot be revised when a reason changes; a sequence with no alternative is being presented as universal, and no sequence is.
One possible sequence for the store
The order below is the one the lesson defends. Read the reasons rather than the steps: each names a dependency, a risk or a value, and a step that could not name one would be suspect. The alternative at the end is not a footnote; §82 says the sequence is one possible sequence, and a device that presented it as the sequence would be teaching the thing this domain warns against.
- 1Product model, and a script that creates a few
because Everything else displays or sells a product; a script means admin is not on the critical path.
- 2Display products: endpoint and page
because The least content that makes the system run end to end, so every later step is a change to a running system.
- 3Cart: add, remove, survive a refresh
because Checkout needs a cart, and the persistence decision is easier to make on a real cart than on paper.
- 4Checkout without payment: validate, total, create the order
because The whole customer workflow becomes testable before the riskiest integration; the price-snapshot and empty-cart questions surface here.
- 5Order persistence and an order page
because An order that vanishes on restart is not an order; the page proves the customer can find it again.
- 6Payment — integration, after a week-one spike
because There is now an order to pay for, and the spike has answered who is authoritative for "paid" before code depends on it.
- 7Failure handling: timeout, duplicate click, sold out, provider down
because Each failure is injected against a checkout that works, so the change and the effect are both small.
- 8Admin: create and edit products
because It replaces the script; nobody was blocked by its absence, so it carries the least urgency.
The question that decides the order
Most arguments about order are arguments about a badly asked question. "What should I build first?" has no answer; the ladder below sharpens it until it does, and the best form is the one the lab at /thinking/first evaluates — features with dependencies, risk, value and effort, and a recommended order that changes when the weights do.
why The best form makes the order computable from things you can write down — dependencies, risks, values — and makes disagreement productive: two people who disagree about the order can find which weight they disagree about. The vague form can only be answered by taste.
The step that makes the rest into loops
Step two above is small and it is the most important step in the sequence, because it is the one that turns a plan into a running system. The slice below is what it contains, what it proves, and — the honest half — what it does not, which is most of the store.
- DatabaseOne product row: id, name, price, stock.
- BackendAn endpoint that reads the row and returns it.
- FrontendA page that calls the endpoint and renders name and price.
How to do it
Most important first.
- For each piece in the decomposition, write what it requires — data, another piece, an external answer. The pieces with nothing required are the candidates for first (Dependency First).
- Among the candidates, prefer the one that gets the system running end to end soonest. For the store that is a product that can be displayed, not a product that can be edited.
- Mark the piece with the largest unknown and find the earliest point in the sequence where a spike on it is possible. Put the spike there, even if the integration comes much later (Spikes).
- After each step, ask what a customer can now do. If the answer has not changed in two steps, the sequence has drifted into polish or infrastructure (Value First).
- Keep the failure handling for a step immediately after that step's happy path, not in a "hardening" phase at the end; failures are injected against something that works (Failure Path Second).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The store, ordered. Product model first, because everything displays or sells a product. Display products, because it makes the system run end to end with the least content. Cart, because checkout needs one. Checkout without payment, so an order can exist and the whole workflow is testable before the riskiest integration. Order persistence, so the order survives a restart and can be shown again. Payment, now that there is an order to pay for and the spike from week one has answered "who says it is paid?". Failure handling — timeout, duplicate click, sold out — against a working checkout. Admin last, because until now products were created by a script and nobody was blocked.
- The reason each step can be defended. "Why is admin last?" Because a script creates products and no customer needs the panel. "Why is checkout before payment?" Because an unpaid order is a complete workflow to test against, and payment then attaches to something. "Why is the payment spike in week one if payment is step six?" Because the spike is not gated by an order existing and its answer might change the shape of checkout.
- The alternative, for a different team. A team that has never used this provider and has heard it forces a hosted checkout page would prototype payment first — a test-mode charge with no store around it — because if the provider dictates the checkout flow, building checkout before knowing that is building it twice.
- The chat app, ordered the same way. User and conversation models; send a message and see it on refresh; see it without refresh; read state on one device; read state on two devices, which is the unknown pulled forward as a spike in week one; then attachments and search, which no workflow needs to exist.
How you know it worked
What now exists that did not before, and what question you can now ask.
- A written sequence exists in which every step has a reason that refers to dependency, risk or value — not to interest or ease.
- A customer can complete something end to end earlier in the sequence than in the plan you started with.
- The riskiest unknown has a spike scheduled at the earliest point its dependencies allow, separated from its integration.
- At least one alternative sequence is written down with the condition under which it would win.
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 does each piece require to exist before it can be built, and which pieces require nothing?
- ?What is the earliest step at which a user can complete something end to end?
- ?Which unknown carries the most risk, and where is the earliest point I can spike it without waiting for its integration?
- ?What is one other defensible order, and what would have to be true for it to be better than mine?
What can go wrong
- The sequence is optimised into a critical-path diagram with durations, dependencies and float, and a week passes. The sequence needs to be defensible, not optimal; when the first step is obvious, start it and revise the rest after.
- Risk-first taken to the point where nothing runs. Every spike is done before any slice, and after a month the team knows a great deal about payment providers and has no store. Spikes are pulled forward to where dependencies allow, not to the front of everything.
- The sequence is treated as fixed once written. The payment spike may reveal that the provider needs an order id before charging — which reorders order persistence and payment. A sequence with reasons is revised when a reason changes.
- Failure handling deferred to a "hardening" phase because the sequence lists happy paths. Each step's failures belong right after it, while the happy path is fresh and small.
- Ordering by value and risk means the interesting piece — the one that would have kept you motivated — may be last. On a solo project that cost is real, and sometimes the right call is a small piece of the interesting thing early, labelled as such.
- Checkout without payment is a step that produces an order nobody has paid for, and to a stakeholder that can look like the wrong thing built. The reason has to be explained.
- A written alternative invites the argument about which order is right. The reflex avoids the argument by never writing an order down.
- "This is the order for stores." It is one defensible order for this store with this team. A team with payment experience pushes payment later; a team with none pulls it first; a store whose founder must demo the admin panel to investors next week has a different value function and a different order.
- "Dependency-first means build the database completely first." Dependency is between capabilities — checkout needs a cart — not between layers. A complete database before any page is the horizontal-layers trap wearing a dependency argument (The Horizontal Layers Trap).
- "Risk-first means the scariest thing gets built first." The scariest thing gets spiked first — a small experiment that answers its question. The integration waits for its dependencies like everything else.
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 and value are the three questions for any sequence, whether the pieces are features of a store, modules of a library or stages of a pipeline; the weights among them change with the project, the questions do not.
- TEAM-SPECIFICA solo learner should weight learning value higher than a team under deadline would — building the unfamiliar piece early is the point of the project. A team with experience of the payment provider has no risk there and would sequence it late without a spike.
- CONTESTEDSome practitioners hold that ordering is overrated: that on a small team with fast iteration any order converges within a few loops, that time spent sequencing is time not spent building, and that the cure for easiest-first is simply to build a walking skeleton and then take whatever the running system complains about next. That view is strongest for experienced teams on familiar products, where the risky unknowns are already known and the sequence is habit.
- ILLUSTRATIVEThe three days on the admin panel, the week-one payment spike and the hosted-checkout provider are invented to give the sequence a shape; no real project or provider is described.
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 this sequence in ten stages with feedback only; the order above is its spine.