A way to build software with AI where you do the thinking and the AI does the building. You design it on one page, make the AI argue with it, then let it build inside the structure you decided.
The tools got fast. The thinking didn't move. Most AI-built software fails before the first prompt: nobody drew the flow, nobody asked where it breaks, and nobody decided where a human has to say yes.
You describe the app in a chat box, it builds something plausible, and you rebuild it three times as you discover what you meant.
Ask an assistant if your idea is good and it says yes. If it never pushes back, you're not designing. You're decorating.
Let the tool pick the stack and the folders, and you inherit a codebase nobody can explain, including you.
I lost $20,000 paying other people to build what I'd specified but couldn't see. Paper-first is what I do now.
The AI is brilliant at the third. It's only safe when the first two are done by a person.
One page, pen not keyboard. The flow, the journey, the architecture. Where the AI sits, and where a human must say yes.
Read the page out loud to Claude and make it disagree. Five questions, until the page is honest. Then you decide the architecture and the stack.
A six-line brief becomes one build prompt per service. The AI builds inside your structure. You review like an architect, ship, and go back to paper.
I use Claude to think and Cursor to build. The method doesn't depend on either. Swap in your tools; keep the order.
One sheet, three boxes, before you touch a tool.
A voice session, 20 to 40 minutes. Read the whole page first, no questions. Then ask:
Boxes become services. Data becomes stores. The star becomes a retrieval step, a reviewer and a confidence gate. The hand becomes an approval nobody can skip.
You decide. Claude checks.
Whatever the product needs. The stack is your call, because you'll own it in production. The AI can suggest; it doesn't decide.
Claude turns the page and this brief into one build prompt per service, each with the files to create, the tests to write, and the line that says it's done.
The AI builds in the structure you decided, one service at a time. A hundred revisions is normal. After every service, five checks: structure, failure paths, the gate, the NEVER lines, hand-over.
Deploys from main. Seeded demo data. A runbook with three lines: restart, who to call, rollback. Then the next page.
The exact templates I use. Copy them into your notes, or download them as Markdown. Free, no email.
Three boxes on one sheet: flow, journey, architecture.
FLOW who starts → sees → gets → ends JOURNEY first use · hard case · the save ARCHITECTURE services · data · ★ AI · ✋ human
The script for the voice session, with what a good answer looks like.
1 What's missing from the flow? 2 Which idea is bad, and why? 3 Where does it break at 10x? 4 What happens when the AI is wrong? 5 What's the simplest architecture left?
Six lines, with a filled example from a real build.
STACK · STRUCTURE · AI RULES · DONE · NEVER
Five checks after every service, before the next one starts.
structure · failure paths · the gate NEVER lines · hand-over
Free to use and share with credit: “The Paper-First Method by Sohaib Waheed” (CC BY 4.0).
I spent years writing specs for software I couldn't build myself, and paying other people to build it. In 2021 that cost me $20,000. So I learned the part I couldn't see: architecture, retrieval, agents, the code.
The Paper-First Method is the process that came out of it. Paper, a voice session with Claude, the architecture, the stack, the prompts, Cursor, deploy. It's how I've built 25–30+ applications, and how my company, Zaltech AI, builds today.
Take the templates. Draw the page. Make the AI push back.