You block out an evening to finally start your build, and by ten o'clock there are forty tabs open: hosting providers compared in someone else's spreadsheet, a thread arguing about databases, a video on the ideal folder structure. Every tab produced notes and none moved the build, because reading can go on forever while shipping is something you actually finish.
The fix is a plan small enough that you cannot keep researching behind it.
A Build Plan is one page with six fields, finished when the page is full rather than when the reading runs out.
This chapter walks you through the fields, sequences the month that follows, and ends with the first hour of actual building.
The six fields of a Build Plan
Each field just records a decision this level already walked you through. We will fill a plan for the meeting-prep one-pager from Find your build and pick its shape, the page that turns tomorrow's calendar and your scattered notes into a single brief for every call.
What I am building. One sentence that names the thing and the job it does. If you cannot say it without piling on more and more clauses, the build is still too big.
Who it is for. The specific person with the problem, never the market around them. The strongest answer is still you, the first user who learns fastest whether the thing helps.
The user's journey. Three to five steps from arrival to value, each one a short sentence. Anything off the path to the value gets cut, however attractive it sounds.
The stack. Your pick for each layer this level toured, frontend through monitoring, with a one-sentence defense each. Defaults are the strong answer, and a tool you have never used has no business in a v1 plan.
Where AI fits. The role audit from Where AI fits in your product, a yes or no on each role, with every yes naming what the model will actually do. Each extra yes adds cost and work, so keep them to the ones you need. For a runtime yes, the Model Spec you wrote in The Model Layer is the detail behind it: the model, the prompt, the output structure, the context, and the fallback.
The smallest thing I can build first. The version you could put in front of yourself within a week, picked to teach the most about whether the idea is real. The first hour runs on this field.
Here is the one-pager's plan, filled in.
Build Plan: the meeting-prep one-pager
What I am building. A web page that turns tomorrow's meetings and my raw notes into one brief for each call.
Who it is for. Me first, then any product manager who runs back-to-back calls and keeps walking in cold.
The user's journey. Paste tomorrow's meetings and the notes for each one. Get back one brief per call: what was promised last time, what is still open, what I want from the next half hour. Skim it before the call.
The stack. One Next.js project for the page and its API route, no database because nothing is stored, a serverless host's free tier, no login while the only user is me, built-in host logs as monitoring.
Where AI fits. A yes on writing the code and a yes at runtime, where the model generates each brief from the pasted notes; the other roles stay no.
The smallest thing I can build first. A single page where I paste one meeting's notes and get one brief back, live before tomorrow's first call.
Draft yours in twelve minutes
Open the Build Plan tool and give each field two minutes and your first honest answer. The draft saves on your device as you type, nothing reaches our servers, and the finished page exports as a PDF, an email to yourself, or Markdown. Twelve minutes is the whole budget, because a longer sitting invites the research project back in.
A field that refuses to fill points at the one decision you have not made, and the chapter covering it is a short reread away. When the page is full, step away for ten minutes, then return and fix what most first drafts get wrong.
- The journey runs long. Cut it to the steps that produce the value, and question every survivor.
- The stack names a tool you have never used. It got in because it sounded sophisticated; swap in the default you can defend in one sentence.
- Field six still describes the whole product. Keep removing features until one week of evenings could ship what remains.
Four weeks from plan to public link
The build then runs on a sequence that has fit nearly every project we have shipped or coached.
Week one builds the smallest useful version. Field six end to end: built, deployed, and used by you for real work before the week is out. The bar this week is useful, not impressive.
Week two adds the one feature the smallest version exposed as missing. A week of real use tells you what is missing far more reliably than any planning session could. For the one-pager it was the calendar pull, because pasting meetings in by hand turned irritating by day three. Build that feature and nothing else.
Week three makes it not embarrassing. Edge cases, empty states, and enough visual care that the link could go to a stranger without an apology. Nothing new gets added; what exists gets finished.
Week four runs the guardrails and the legal pre-flight. Before anyone but you touches the build, run the checks from Guardrails: keep secrets, money, and data safe and the pages and disclosures from The legal basics every public build needs. Then the link goes out.
The first hour of the build
Week one starts with a single hour, and the hour has a set structure.
- Open your tool. Claude Code, in a new empty folder named for the build.
- Paste your project brief. The three sentences from Working with AI as a builder: who it is for, what it does, what it must never do.
- Ask for the smallest version. Hand over field six word for word, and ask for a plan before any files change.
- Make a save point. Commit, the undo from Git: the undo that makes AI edits safe, so everything after this is reversible.
- Read the diff. The pass from Review what the AI built: names make sense, changes match the ask, nothing arrived unrequested.
- Run it. Open it in your browser and use it once for real, because a confident session summary is not evidence that the page loads.
An hour spent this way leaves you with working software, which all the research tabs in the world never produce.
What comes after this level
This chapter closes The Fundamentals. The questions that stopped you at Decode the technical questions that stop you now read as decisions you know how to make, and the open question shifts from vocabulary to trust: can the people using it tell when the model's output deserves doubt, and do your warnings get noticed. The Practice is the next level, its job is making a working build trustworthy, and the reasoning behind it lives in our essay The Human Factors.
Try it now
No setup: Complete the six fields in the Build Plan tool and export the result as a PDF, an email to yourself, or Markdown. Hold the two-minute limit per field, and put the export somewhere you will see it this week.
With your tools: Run the first hour against field six tonight: open Claude Code in an empty project folder, paste your project brief, hand over field six, and work the list above through to a page that loads. If your tools are not set up yet, The Setup Clinic gets you to a working session in one sitting. In Codex or Cursor the move is the same: open the sidebar chat in an empty project, paste the brief and field six, and review the plan and the diff before accepting anything.
Chapter Summary
- A Build Plan is one page with six fields, and you are done when the page is full, not when you have finished reading about it.
- The six fields are what you are building, who it is for, the user's journey, the stack, where AI fits, and the smallest thing you can build first.
- Each field just records a decision this level already walked you through, so a field you cannot fill points at one decision you still need to make.
- Draft the whole plan in about twelve minutes, two minutes a field, then fix the journey that runs too long, the stack naming a tool you have never used, and the field six that still describes the whole product.
- The build runs over four weeks: week one ships the smallest useful version, week two adds the one missing feature real use revealed, week three makes it presentable, and week four runs the guardrails and legal checks.
- Do not send the link until week four is done, because that is the week that makes the build actually safe to share.
- Week one opens with a single hour: open your tool in an empty folder, paste your project brief, hand over field six, make a save point, read the diff, and run it.
- The Fundamentals ends here. Next is The Practice, which shifts the work from getting your build running to making it something people can trust.