I Have No Idea Where to Begin
"Build an e-commerce store" is not a task, it is a sentence. Before any technology, ask what it means: who uses it, what they do, what data exists, what must persist, what can wait — until the smallest useful version is visible and the next question is obvious.
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.
Someone hands you "build an e-commerce store" and you have never built one. What do you do in the first hour, and how do you know it was the right hour?
A founder says "we need an online store, can you build it?" You have built CRUD apps and followed a few tutorials. You open a blank editor, then a blank document, then a browser tab that says "best stack for e-commerce 2026", and forty minutes later you have eleven tabs and nothing written down.
Pick the stack. It is the one decision that feels fully within your control: React or Next.js, Postgres, maybe Stripe, maybe Redis for the cart. Choosing it produces a repository, a folder structure and a running dev server, and every one of those looks like the project starting.
The repository exists and the problem has not moved. Nothing in the folder structure says what a customer can do, what an order is, or what happens when a payment fails — so the next thing to build is chosen by what the framework makes easy, not by what the store needs.
- The repository exists and the problem has not moved. Nothing in the folder structure says what a customer can do, what an order is, or what happens when a payment fails — so the next thing to build is chosen by what the framework makes easy, not by what the store needs.
- The tutorial that "builds an e-commerce store" builds *its* store. Its cart is client-side because that made the video shorter; its checkout skips payment failure because that made the video watchable. You inherit decisions you never made and cannot defend.
- Every unknown stays vague. "Payments" is still one word; so is "inventory". Vague unknowns cannot be researched, so they are postponed, so the first slice of the store is whichever part had no unknowns — usually a product list — and the hard parts arrive last, when there is least time.
- When a stakeholder asks "what will V1 do?", the honest answer is "whatever the stack supports by then". That is not a plan; it is a hope with a dependency list.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Treat "I do not know how to build this" as a *location* rather than a verdict: it means you are before the Understand step of the loop, and the loop says what comes next. You do not need a solution to make progress; you need the next question, and the first questions are always the same — who uses it, what they do, what the most important workflow is, what data exists, what must persist, what is outside the system, what can be ignored in V1.
- Ask those questions of the sentence you were given, and write the answers down as nouns and verbs, not technologies. "Customer browses products, adds one to a cart, pays, sees a confirmation. Admin creates products and changes stock." The store now has actors, actions and a workflow, and none of it depends on a framework.
- From the actions, name the data that must exist and survive a restart — products, carts, orders, payments — and from the actions and data, name the smallest sequence a customer could complete end to end. That sequence is the smallest useful version, and it decides what to build first far better than the stack does.
- Write what you do not understand as a list, and rewrite each item until it is a question someone could answer. "Payments" becomes "how does my backend find out that a payment actually succeeded, and who is authoritative?" The list is the research plan. Technology gets chosen *after* this, because now there is something to choose it for.
The sentence, taken apart
The reflex treats the sentence as a task and looks for tools. The move treats it as a sentence and looks for meaning. The board below is the first hour's output: what is known after asking the seven questions, what is still assumed, and — the part that matters — each unknown rewritten until it is something you could actually go and find out.
Notice that nothing on the known side is a technology, and nothing on the unknown side is a single word. Both are deliberate. A technology on the known side would be an answer to a question not yet asked; a single-word unknown is a worry, not a research item.
- ✓Two actors: customer and admin. Others (warehouse, support) can wait.
- ✓Core workflow: browse → view → add to cart → checkout → order → confirmation.
- ✓Data that must persist: products, orders, payments.
- ✓Outside the system: payment provider, email, image storage.
- ~One warehouse, one currency, one language in V1 — written down so that when any of them changes, we know why the design has to.
- ~Customers must have an account to order. To be checked with the founder; guest checkout changes the cart design.
? Payments.
becomes What sequence of requests happens between my backend and the payment provider during checkout, and which system is authoritative for "this order is paid"?
experiment One endpoint that creates a test-mode payment, one that receives the provider's confirmation, and a log line — with no store around it.
? Inventory.
becomes When two customers buy the last unit at the same moment, what should happen, and where is that decided?
experiment A table with one row of stock and two concurrent decrements; observe what the database does with and without a constraint.
? Images.
becomes Should product images be stored by my server or by an object store, and what does the upload path look like in each case?
experiment Upload one image both ways and note what code each needs and what happens when the file is large.
The board is the deliverable of the first hour. It is not a specification, and it does not need to be complete; it needs to make the next question obvious.
From the sentence to something you could test
Once the actions are known, the store decomposes along them rather than along technical layers. "Frontend, backend, database" is true of every web application and says nothing about this one; "catalog, cart, checkout, orders, payments, admin" says what a customer can do and gives each piece an observation that would show it works.
The leaves are deliberately small and deliberately testable. A leaf you cannot describe a test for is a heading that has not been decomposed yet.
- ├Catalog— the customer's first action
- └List productstestable GET returns the products that exist in the database, and a page renders them.
- └View one producttestable A product page shows name, price and stock for a real product id; a missing id gives a clear not-found.
- ├Cart— the bridge between browsing and buying
- └Add and remove itemstestable After adding twice and removing once, the cart holds one item with the right quantity.
- └Cart survives a refreshtestable Reloading the page shows the same cart — the persistence decision made explicit.
- ├Checkout— the workflow that makes it a store
- └Validate items and totaltestable A cart with an out-of-stock item is rejected with a reason; the total matches the sum of current prices.
- └Create the ordertestable A checkout produces exactly one order with the cart's items and prices captured at that moment.
- └Take paymenttestable A test-mode payment succeeds and the order becomes paid; a failed payment leaves it unpaid and says so.
- ├Admin— someone has to create the products
- └Create and edit a producttestable A product created in the admin appears in the catalog with the same price and stock.
Every leaf can be built and checked in isolation, and together they cover the core workflow. Recommendations, coupons and search are not in the tree because they are not in V1.
The order of work, and why it is not the only one
With the decomposition in hand, an order of work follows from dependencies, risk and value rather than from what the framework makes easy. The sequence below is defensible: it builds the skeleton first, reaches a working store without payment early, and researches the riskiest unknown before it is on the critical path.
It is also not the only defensible sequence, and the device says so. A team that has integrated this payment provider before has no risk there and would push payment to the end; a team that has never done it might prototype payment on day one, before a single product exists.
- 1Product model → endpoint → page (the walking skeleton)
because Proves that the three layers connect and that the environment works, with the least possible content.
- 2Display products; admin creates them
because The catalog is the first customer action and every later step needs products to exist.
- 3Cart, with the persistence decision made explicit
because Checkout cannot be built without a cart, and the anonymous-vs-account question decides the cart's shape.
- 4Checkout without payment: validate, total, create order
because Reaching "an order exists" without the provider means the core workflow is testable before the riskiest integration.
- 5Payment research spike, then integration
because The unknown with the highest risk goes before polish; the spike answers "who says it is paid?" before the code depends on the answer.
- 6Failure handling: payment timeout, duplicate click, sold out, database down
because The happy path is understood, so each failure can be injected against something that works.
- 7Production concerns, then scale only on evidence
because Logging, deployment and security come before real users; a cache comes after a measured bottleneck, not before.
How to do it
Most important first.
- Before touching a tool, write one paragraph saying what the thing is, in the language of the person who asked for it. If you cannot, the next step is a conversation, not a repository (Problem Framing).
- List the actors and, for each, the actions they take. Keep the verbs concrete — "adds a product to a cart", not "manages cart" (Requirement Discovery).
- Mark the one workflow whose completion means the store works. For a store it is browse → view → add to cart → checkout → order created → confirmation. Everything not on that path is a candidate for "not V1" (MVP Thinking).
- Name the data the workflow touches and which of it must persist. Products and orders must; a browsing session probably need not (What Must Persist).
- Name what is outside your system — the payment provider, email, image storage — because each one is a boundary that can fail and a thing to research (Where Does My System End?).
- Write your unknowns and sharpen each into a question with a tiny experiment attached (Unknown to Specific Question). Then, and only then, pick the first vertical slice and the technology it needs (What to Build First).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The sentence: "build an online store". Actors: customer, admin. Customer actions: browse products, view a product, add to cart, check out, see the order. Admin actions: create a product, change a price, change stock. Core workflow: browse → view → add to cart → checkout → order created → confirmation. Nothing here names a technology, and it took twenty minutes.
- Data that must exist: Product, Cart, CartItem, Order, OrderItem, Payment. Must persist: products, orders, payments. May persist: carts (a decision to make later — anonymous carts complicate it). Outside the system: the payment provider, an email sender, wherever product images live.
- Not V1: recommendations, coupons, multiple warehouses, search beyond "filter by name", reviews, multi-currency. Each of these was on the founder's list; each is written down as "later, and here is why" rather than silently dropped.
- Unknowns, sharpened: "payments" → "what sequence of requests happens between my backend and a payment provider when a customer checks out, and which system decides the order is paid?" Experiment: one endpoint that creates a test-mode payment and one that receives the provider's confirmation, with nothing else in the app. "Inventory" → "what should happen when two customers buy the last unit at the same time?" Experiment: a table with one row and two concurrent updates.
- First slice: a product in a database, an endpoint that returns it, a page that shows it. It is tiny and it proves the three layers connect. Only now does the technology question have content: something that can render a page, serve an endpoint and persist a row — and almost anything you already know will do.
How you know it worked
What now exists that did not before, and what question you can now ask.
- A page exists that a non-engineer could read and recognise as their store — actors, actions, the core workflow, what is not in V1 — and none of it mentions a framework.
- Every unknown on your list is a question with a verb in it, and each has an experiment small enough to do this afternoon.
- You can say what you will build first and why — and the reason is about the problem (dependency, risk, value), not about the tool.
- The stack question has become boring. Several choices would work, and you can say which constraints would make you prefer one.
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 is this thing, in one paragraph, in the words of the person who asked for it?
- ?Who uses it, and what does each of them actually do?
- ?Which single workflow, if it works end to end, means the thing works?
- ?What data has to exist, and what has to survive a restart?
- ?What is outside my system, and therefore able to fail without me?
- ?What do I not understand — and what is the specific question hiding inside each vague word?
- ?What is the smallest slice that touches every layer, and what would I learn by building it?
What can go wrong
- The hour becomes a week. The actor list grows to twelve, the workflow diagram has swim lanes, and the first slice still has not been built. The move is meant to produce a *next question*, not a complete specification; when the next question is obvious, stop framing and go answer it.
- The questions are asked but the answers are guessed. "Who uses it?" is answered from imagination instead of from the founder, and the store is built for a customer who does not exist. The move requires talking to whoever asked.
- The unknowns list is written and then filed. An unknown that has become a question still has to be answered; the list is a research plan, and a plan not executed is a worry with formatting.
- The move is applied to a problem that was already understood. Someone who has built four stores does not need the hour; they need the one question that makes this store different. Recognise when the loop can start further along.
- The first hour produces no code, and to someone watching it looks like nothing happened. On a problem you already understood, it was an hour lost.
- Writing "not V1" down in front of a stakeholder invites an argument about scope that picking a stack would have postponed — but only postponed.
- Sharpened unknowns are more work than vague ones: "payments" is one word to worry about, and its sharpened form is an afternoon of reading and an experiment.
- "So the first step is to write a spec." No — the first step is to write enough that the next question is obvious. A spec is a document; this is a list of actors, actions, data, boundaries, unknowns and one slice, and it fits on a page.
- "Technology choice doesn't matter." It matters; it just does not come first. A store that needs server-side rendering for search engines and one that is an admin tool behind a login make different choices — and you can only tell which you have after asking who uses it.
- "This is what senior engineers do instead of coding." Senior engineers do it *faster* and often in their heads, which is why it looks like they start coding immediately. The questions are the same; the visible hour is the beginner's version of a habit.
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.
- GENERALThe questions — who, what actions, which workflow, what data, what is outside, what can wait — apply to any product-shaped problem; for a library or a pipeline the "actors" are callers and the "workflow" is one call, and the move is unchanged.
- STAGE-SPECIFICOn a greenfield store the hour is spent discovering; on an existing store the same questions are answered by reading the current system, and the move becomes locating where the new requirement fits rather than inventing the shape.
- ILLUSTRATIVEThe online store, the founder, the twenty minutes and the eleven browser tabs are invented to show the shape of the move; no real project is being described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto's "What Are You Delegating?" cards at /manifesto/delegating show what a payment SDK handles for you and what stays yours — read one before the payment spike.