Stage 3 — The documents most solo founders skip. That's why their builds go sideways.

By the time an idea reaches Stage 3, it has survived a problem statement test, a user definition pass, a credit card question, a dependency audit, and a documented go/no-go decision. The work is real. The momentum is real. And that momentum is exactly what makes Stage 3 dangerous — because the temptation to skip it and start building is at its absolute peak right here.

Most solo founders give in to it. They open a build tool, paste in a rough description of the app, and start iterating from whatever the AI produces. The result isn't always a disaster. Sometimes you get something that works. But working isn't the same as right, and the gap between what the build tool assumed and what you actually wanted tends to surface at the worst possible time — deep into the build, when reversing a wrong architectural decision costs hours, not minutes.

Every question left unresolved in Stage 3 becomes a bad assumption made by your build tool during Stage 4.

That's not a warning. It's a mechanical description of how AI-assisted builds fail. The build tool isn't guessing carelessly — it's filling silence with the most plausible answer it can construct from what you gave it. If you didn't tell it whether auth is required, it will decide. If you didn't tell it whether the app needs a database, it will decide. Stage 3 is the stage where you make those decisions first, on your terms, with your context — not the tool's.

Two documents. Two audiences. Never conflated.

Stage 3 produces exactly two outputs, and they are deliberately separate. The first is the Business & Strategy Doc. The second is the Technical Spec. They are written for different readers, serve different purposes, and should never be merged into one document — because the moment you hand your build tool a document containing business rationale, brand positioning, and monetization philosophy alongside the technical spec, you've introduced noise into what should be a clean set of build instructions.

Document	Written for	Contains
Business & Strategy Doc	You and future partners	Product manifesto, target audience, SWOT, monetization model, portfolio context, pre-launch action items
Technical Spec	The build tool AI — exclusively	Opening build prompt, all architecture decisions resolved, data model, core logic in JavaScript, screen flow, feature priority tiers (P0/P1/P2), edge cases, sandbox validation scenario with exact expected outputs

The Business & Strategy Doc is the vision document. It's where the founder's intent lives — why this app exists, who it's for at a human level, what winning looks like, and what needs to happen before launch that has nothing to do with code. It's also the document you'd hand to a future collaborator to answer the question "what is this and why does it matter?" It belongs in your Claude project knowledge base, not in a build prompt.

The Technical Spec is a different animal entirely. It's a contract. It tells the build tool exactly what to build, in what order, with what logic, handling which edge cases, producing which outputs given which inputs. There are no open questions in a finished Technical Spec. There are no statements like "the app should probably..." or "we'll figure out sharing later." Every one of those hedges becomes a build tool assumption. A spec with five open questions produces a build with five wrong guesses baked in from the first session.

The decision checklist — answer these before you write a word of the spec

The Technical Spec can't be written until a specific set of architectural decisions are locked. These aren't preference questions — they're load-bearing choices that cascade through every part of the build. Leaving any of them open means the spec has a hole, and the build tool will fill it.

• Platform: web app, native iOS, native Android, or PWA? Each has a different build tool, cost, and distribution path.
• Auth: login required, or zero-login? Zero-login apps are faster to build and lower friction to try. Login opens up persistence and personalization but adds a full authentication layer.
• Backend: database required, or stateless? Stateless is dramatically simpler. If the app can do its job without storing user data between sessions, start there.
• Sharing: how does a second user see another person's work? Link-based? Account-based? Read-only or editable? This single decision affects data model, URL structure, and auth requirements simultaneously.
• Scale ceiling at launch: how many items, users, or records does the app need to handle? Not a growth projection — a design constraint.
• Feature priority: what is P0 (MVP must-have), P1 (should-have for a strong launch), P2 (backlog)? Everything that isn't P0 gets cut from the first build.
• Monetization touchpoint: where exactly does revenue touch the product — which screen, which action, which moment?

Working through this list is the actual work of Stage 3. The documents are the output of the decisions, not the other way around. You can't write a clean spec without having answered every item above. If you try, you'll find yourself writing hedges — and hedges are just unresolved decisions wearing a friendlier name.

The core logic comes before the UI

One of the most important things the Technical Spec contains is the core calculation or business logic written out in JavaScript — validated against a sandbox scenario with exact expected inputs and outputs — before a single screen is designed. This is the discipline that most solo builders skip second, right after skipping Stage 3 entirely.

The reason it matters is sequencing. Build tools are eager to make things look good. Give one a description of a bike fit app and it will produce a UI with sliders and score displays before it has any idea whether the scoring logic is correct. You end up testing the wrong thing — the interface — while the engine underneath it is still full of assumptions. The core logic has to be right first. Once it is, building the UI around it is fast and clean. Once it isn't, no amount of UI polish will fix the outputs.

For apps with any kind of calculation, recommendation, or scoring engine — which covers most of the apps in the Wilde DataLabs pipeline — the JavaScript logic goes into the spec, gets validated against a hand-calculated sandbox scenario, and the expected outputs are documented explicitly. The build tool gets the logic. The sandbox gets used to verify the build tool implemented it correctly. This is the only reliable way to know that Stage 4 produced what Stage 3 specified.

The opening build prompt

The last output of Stage 3 is the opening build prompt — the exact text you paste into the build tool to start Stage 4. Not a summary. Not a rough description. The verbatim prompt, written with the precision of the spec it was derived from, designed to prime the build tool with the right context, constraints, and sequence before it writes a single line of code.

Writing the opening build prompt is a useful forcing function even before Stage 4 begins. If you can't write a tight, unambiguous build prompt from your spec, the spec isn't done. A well-written spec produces a build prompt almost automatically — the decisions are already made, the logic is already validated, the priority tiers are already set. The prompt is just the spec translated into the build tool's register.

This prompt gets pasted verbatim in Stage 4. Not paraphrased. Not summarized. Verbatim. The discipline matters because paraphrasing introduces exactly the kind of ambiguity the spec was designed to eliminate.

What Stage 3 feels like to skip

I've built apps by skipping Stage 3. The experience is recognizable: the first few hours feel fast, the build tool is generating screens and components, things look like they're taking shape. Then you hit the first decision the tool made silently that you would have made differently — auth structure, data schema, how state is managed across screens. You correct it. The tool adapts. But now the early code and the corrected code share an inconsistency, and the tool doesn't always reconcile it cleanly. By hour six you're debugging things that were never in the spec because there was no spec. By hour ten you're considering a rebuild.

Stage 3 takes a day. Sometimes two. It feels slow relative to the momentum that built up through Stages 1 and 2. It is the most important day in the entire lifecycle — not because the documents are valuable artifacts in themselves, but because the act of writing them forces every ambiguity into the open before the build tool can silently resolve it the wrong way.