How Do You Write a SaaS Spec With Claude Before Coding?
Have Claude interview you until it can write a one-page spec to SPEC.md, and cut that spec down yourself. Then start a fresh session and build from the file. You end up with a written definition of done, which gives Claude a target and gives you something to check its work against.
I want to build [one sentence: the product and who it's for]. Interview me until you could write the spec, then write it to SPEC.md. Ask one question at a time, and start with the riskiest unknown. The spec must fit on one page and contain: - the primary user, and the one problem this solves for them - 3 to 5 must-have features for v1, each with a testable acceptance line - what is explicitly out of scope for v1 - the main data entities - how we'll know v1 is done Push back on scope. For anything nice-to-have, argue for cutting it. Don't write any code yet.
- 1Claude interviews you
- 2It writes SPEC.md
- 3Build in a fresh session
- 4Review the diff against SPEC.md
Try it now
- 1In your project folder, start Claude Code by running
claude. Paste the prompt with your real idea. - 2Answer its questions, then open
SPEC.mdand delete every feature you could launch without. - 3Run
/clearto start fresh, then send: "Read SPEC.md and build the first must-have feature only." - 4You'll know it worked if each feature has an acceptance line you could test yourself. No Claude Code? Do the interview in a Claude project, and save the result in project knowledge.
Use it when
Use it at the start of any app you plan to keep and put in front of paying users, especially if the idea is still fuzzy. It also helps before a large new feature on an existing product.
Skip it when
Skip it for a throwaway prototype, where the point is to learn fast and throw it away. A clickable artifact teaches you more there. Also skip it for small changes you could describe fully in one sentence.
Why it works
Claude Code's best-practices docs say that when a session goes wrong, Claude often built something different from what you had in mind because it was missing information it can't get from the repo. They suggest the prompt "Interview me until you could write the spec, then write it to SPEC.md". Starting a fresh session afterward means the build begins with a clean context and a written definition of done. Rule of thumb, not a vendor figure: keep v1 to three to five features. Cutting a line from a spec takes seconds, and removing a built feature doesn't.
Example
You want a client-invoicing tool for freelancers. The interview asks whether clients need accounts, and you say no. The spec lists create an invoice, send it by email with a link, and mark it paid. Out of scope are multi-currency, team accounts and a dashboard. Acceptance for sending reads: "A client can open the link without signing in and see the total."
Going further
Don't import a long spec into CLAUDE.md with @SPEC.md. The memory docs say imported files are loaded alongside it in every session, and they target under 200 lines per CLAUDE.md. Name the file in your prompt instead, so Claude reads it when needed. At the end, review with a subagent, using the docs' wording: use a subagent to review the diff against SPEC.md, check every requirement is implemented and the listed edge cases have tests, report gaps that affect correctness and skip style. They warn not to drop skip style, because a reviewer asked to find problems will always find something.
Common mistakes
- Opening with "build me a SaaS that..." and letting scope emerge one feature at a time.
- Accepting Claude's first spec without cutting it. It will happily list everything you mentioned.
- Writing acceptance lines like "works well" that nobody can fail. Each must be something you could test.
- Building in the same session as the interview, which carries all the abandoned ideas forward.
Sources
Checked 6 November 2026. Products change often, so confirm details with the vendor.