Every failed build has the same root cause: someone started coding before they finished thinking. This method makes the thinking explicit, sequential, and documented — so the build is execution, not exploration.
I build automation systems and intelligent workflows using AI — Google Workspace, Apps Script, Copilot Studio, Claude API. No formal engineering background. What I have is 25 years of domain depth and a method that separates thinking from building so cleanly that by the time I write the first line of code, every decision has already been made.
The method produces nine artefacts. Each one exists because the previous one surfaced a question that needed answering. Skip a stage and the next stage is built on assumptions instead of decisions. The sequence matters.
Every hour spent in pre-build saves five in rework. I know this not from theory but from the builds where I skipped stages and paid for it later — in code that had to be thrown away, in features that didn't fit, in UX that made sense on paper and fell apart the moment someone tried to use it.
"The build should be execution, not exploration. Every decision was made in Stages 1–8. Stage 9 is where you type, not where you think."
The spark. The raw idea before anyone tries to make it sensible. Write it in plain language. What's the problem? Who has it? What would "solved" look like from their perspective? Don't research. Don't design. Just articulate. The only job is to capture it honestly — before the inner editor cleans it up, before feasibility enters the picture.
Take the genesis note and have a conversation with it. This is the back-and-forth stage — you and Claude going through rounds of "but what about..." and "how would that work when...". The idea evolves here. Features appear. Constraints emerge. The user becomes real — not abstract. Don't lock anything down yet. Explore every branch before you prune.
This is the convergence stage. The iteration gave you breadth — now you define edges. What modules exist? How do they relate? What's Phase 1 vs Phase 2? What gets cut entirely? Think of it as the table of contents for everything that follows. Every module is named. Every data flow identified. The boundary between "ours" and "theirs" is drawn. This is also where you make the hard priority calls — everything can't be Phase 1.
You have the skeleton from Stage 3. Now put flesh on the bones. Take each module and describe exactly what happens inside it — every user action, every system response, every conditional path, every error state. This is where "the user can manage policies" becomes a paragraph of precise behaviour. Work module by module. No hand-waving. No "the system handles this."
Stages 1–4 were exploratory. This stage is definitive. Take everything from the previous stages and compress it into a single, comprehensive requirements document that reads like a contract between the thinker and the builder. The discipline: if something isn't in this document, it doesn't get built. If it's ambiguous in this document, it gets built wrong. This is the single source of truth.
Words lie. Screens don't. Build an interactive HTML/CSS prototype — not a wireframe, not a sketch, but a clickable representation of every screen, every state, every interaction. Build it in Claude as an HTML artifact. Use real labels, real data shapes, real navigation. The goal is to experience the application before investing in building it. This prototype surfaces questions that words never could.
The prototype shows what the application looks like. The UX deep dive documents what it feels like to use. Take each user type. Walk through their entire journey — from first login to daily use to edge-case scenarios. Document what they see, what they do, what the system responds with. Note where the experience is smooth and where it's rough. This is also where accessibility, responsiveness, and performance expectations are documented.
The translation layer — where everything from Stages 1–7 gets compressed into a single technical brief. Technology stack with rationale. Database schema — every table, field, relationship, index. Folder structure. API design. Authentication model. Deployment target. Third-party services. Phased build plan with verification gates. For AI-assisted builds using Claude Code, this document IS the prompt. If the agent has to guess, the document failed.
If Stages 1–8 were done properly, this stage is mechanical. The build document goes into Claude Code. Each phase is executed in order. Each verification gate is checked before moving to the next. The rule: one phase per session. When something discovered during the build contradicts the spec — stop and go back to the document. Don't patch it in code. Fix the spec, then fix the code. The document stays the source of truth even during the build.
Every stage has an exit gate. You don't move forward when time runs out. You move forward when the gate is satisfied. If you find yourself in Stage 6 making decisions that should have been made in Stage 3 — stop, go back, and make them there.
The most commonly skipped stages are Stage 3 (Scope) and Stage 7 (UX Deep Dive). These cause the most pain downstream. Stage 3 because everyone wants to skip from idea to building. Stage 7 because it feels like documentation — but it's actually the last chance to discover UX problems before they're coded into the product.
A software engineer who has never worked in insurance can build an insurance system from a requirements document. The domain expertise is encoded in Stages 1–5. By the time the build document reaches the engineer — or the AI agent — the domain knowledge has been translated into specifications they can execute without needing to understand the underlying problem.
A citizen developer — someone with 25 years of domain depth and no formal engineering background — can now build systems that previously required that engineer. The Pre-Build Method is what makes that possible. Not because it replaces engineering knowledge, but because it externalises domain knowledge into a form that AI can execute.
The citizen developer's advantage is that Stages 1–5 are trivial — they know the domain, the user, the edge cases, the regulatory constraints, the business rules, intuitively. These stages are hard for the engineer. The citizen developer's challenge is Stages 6–8 — the technical translation. This is where AI does the heavy lifting.
The method works because it separates what each party does best. The domain expert thinks. The AI translates. Neither pretends to do the other's job.
Nine stages. Nine artefacts. One working application that matches the spec because the spec was worth building from.
The build is the easy part — if the thinking was done properly. Code is the cheapest part of any software project. Clarity is what costs.
Every hour spent in pre-build saves five in rework.