You have a prototype that works. You built it in Claude over a few weeks, one conversation at a time, and it does the main thing you wanted. Now you want to turn it into a real product, and the first question anyone asks is: what are the requirements?

Most founders point at the prototype and the chat. That is where the decisions are. But try handing that chat to someone else, or to a coding agent, and you find out quickly how much of the product lives only in your head.

There is a step between talking to users and writing a spec that many founders skip. In my process it is called Compile: everything from discovery goes into one plain-language requirements brief. It is not glamorous, but it makes every later step easier.

The chat history is not a brief

Prototyping in Claude is a good way to think: try an idea, see it, change your mind. That is what a prototype is for.

The trouble is what the conversation leaves behind. The decisions are spread across hundreds of messages, some reversed later and some never said out loud. The rules you settled on are mixed in with debugging, abandoned ideas and the model's own guesses. And the people who will use the product were never in the conversation.

The prototype has the same gap. It shows one path working with sample data. It does not say who is allowed to see what, what happens when a field is missing, or which rules the product has to respect.

None of this is a failure on your part or the tool's. A chat records how you got somewhere. A brief records where you are and why, in a form someone else can read in one sitting.

So keep the prototype. It goes in the brief as a reference, and it is more useful as a spec than as a codebase. Just don't let it be the only record.

What goes in it

The brief pulls together everything from your discovery calls and walk-throughs, plus what you learned building the prototype.

  • The problem, in the users' words. One paragraph: who has it, how often, and what it costs them today.
  • The roles. Everyone who touches the work, what each one needs to do and see, and who approves what.
  • The process map. How the work is done today, step by step, including the workarounds and the spreadsheet nobody mentioned at first.
  • The transcripts. Recorded with permission. Consent rules for recording vary, so check your local rules.
  • Sample files. The real forms, spreadsheets, reports and exports people use now. Remove or replace personal data before any of it goes near an AI tool.
  • Constraints. Systems that must stay, devices people work on, deadlines, and where the data has to live.
  • Regulations and standards. Privacy law, industry rules and accessibility standards such as WCAG 2.2. List them here. The spec is where they get researched properly.
  • The one metric that matters. What changes if the product works, and what that number is today.
  • Open questions and what is out of scope. What you don't know yet, and what version one will deliberately not do.

How I structure it

Short body, long appendix. The body should be readable in one sitting, in this order: the problem, the people, how the work happens today, the rules, the metric, then the open questions. Transcripts and sample files go at the back, referenced by name.

A few habits make a brief much more useful:

  • Write facts, not solutions. "Staff type the order number into two systems" is a fact. "Add an integration" is a solution, and it belongs in the spec, after the research.
  • Point to the evidence. Each statement should trace to a transcript, a file or a decision. When a question comes up later, you can check what was actually said.
  • Use plain language. If the brief needs a glossary, it is too technical.
  • Read it back. The people you interviewed should be able to read it and say "yes, that is how it works, and that is what is wrong with it." If they can't, it isn't done.

How the brief becomes the spec

Once the brief is approved, it goes into Perplexity's deep research, which, as Perplexity describes it, runs dozens of searches and reads hundreds of sources before writing a report. I ask it for a detailed spec: users and roles, core flows, the data model, integrations, edge cases, security and acceptance criteria, with a source behind every assumption about the market or the rules.

The research can only be as specific as what you give it. A vague brief gets a generic spec, built from how similar products usually work. A brief with real transcripts, real files and named regulations gets a spec about your product.

Then I read every section, push back where it is wrong, fill in what only the founder knows and lock version one. I wrote about that step in the spec comes before the code.

The spec is what my coding agents build from, whether that is Google's Antigravity working through a long spec overnight or Claude Code, Cursor or Devin on a single change. The brief stays behind it as the record of why.

If you keep working in Claude

If you work in a Claude project, add the brief to the project's knowledge. Claude uses that knowledge as background for the chats in that project, so each new conversation starts from the brief instead of from whatever you remember of the last one.

The rule I follow: when a decision changes in a chat, the document gets updated the same day. The document wins over the chat, and the chat goes back to being a place to think.

A checklist before you write the spec

  1. The problem fits in one paragraph, in the users' words.
  2. Every role is listed, with what each one needs to do and see.
  3. The current process is mapped, workarounds included.
  4. Transcripts and sample files are attached, with personal data removed.
  5. Constraints, regulations and standards are listed.
  6. One metric is named, with today's number.
  7. Open questions and out-of-scope items are written down.
  8. The people who do the work have read it and agreed.

If you're stuck on this step, email me and I'll point you in the right direction.