How-to · October 19, 2026

Write the PRD Before the Prompt: How to Plan a Vibe-Coded Tool

The founders who ship with AI plan first. A step-by-step method, plus a fill-in PRD template for a service-business tool, to stop prompting in circles.

Most people start vibe coding the same way. They open Lovable or Claude Code, type "build me a client portal for my accounting firm," and watch something appear. The first ten minutes feel like magic. By the second evening they are on their fortieth prompt, fixing a bug the AI introduced while fixing a different bug, and the app looks less like their idea than it did at the start.

The people who actually ship with these tools do something different first. They write down what they are building before they ask anything to build it.

That document is called a PRD, a product requirements document. It sounds corporate. In practice it is one or two pages in plain English, and it is the single biggest difference between people who finish and people who give up. This post explains why, gives you a template for a service-business tool, and walks through the loop that turns that document into working software.

Why planning beats prompting

The most watched beginner material on vibe coding keeps landing on the same point. Tina Huang's widely shared fundamentals course starts with structured thinking and a PRD before any prompting. Ryan Carson's popular Cursor workflow is built entirely around turning a PRD into a numbered task list. Greg Isenberg's Claude Code crash course with Ras Mic makes it the first lesson: what you get out depends on what you put in, so plan features and tests before building anything.

The reason is simple. An AI coding tool will always build something. If you have not decided what the something is, it decides for you, one prompt at a time, and every decision it makes is a guess. Guesses compound. By the time you notice the data model is wrong, three features are built on top of it.

Jason Lemkin, the SaaStr founder who has now built several production apps without a developer, put numbers on it in his live guide to vibe coding. Budget about a month for a real B2B app. Expect about 60% of that time to go on testing and fixing. And write a PRD first, using Claude to help structure it. A clear plan does not remove that 60%, but it stops it from growing.

What goes in a PRD

A good PRD for a small tool answers six questions:

  1. Who is it for? Name the actual users. "Our clients" is too vague. "Small business clients who send us receipts monthly" is useful.
  2. What problem does it solve for them? One or two sentences.
  3. What can they do? The features, written as things a person does.
  4. What will it not do? This is the section most people skip and the one that saves the most time. AI tools love to add features. A written "won't do" list stops them.
  5. What data does it hold, and who can see what? This decides your database and your security. Get it wrong and you rebuild later.
  6. How will you know it works? For each feature, a test you can run by clicking.

Keep an "ideas for later" section at the bottom. Every good idea you have mid-build goes there instead of into the next prompt.

A fill-in template for a service-business tool

Here is a template you can copy. The example is a document intake portal for an accounting firm, but the structure works for a clinic's intake form, a law firm's case tracker or a home services quote tool.

# PRD: [Tool name]

## 1. Summary
One paragraph. What it is, who it is for, why it exists.
Example: A portal where our small business clients upload receipts and
bank statements each month, so our bookkeepers stop chasing email
attachments.

## 2. Users and roles
- Client: uploads documents, sees only their own company's files.
- Bookkeeper: sees the clients assigned to them, marks documents processed.
- Admin (partner): sees everything, assigns clients to bookkeepers.

## 3. Core features (version 1 only)
1. Client logs in with email and a magic link.
2. Client uploads PDFs and photos into the current month's folder.
3. Bookkeeper sees a list of clients with missing documents this month.
4. Bookkeeper marks a document as processed.
5. Client gets an email reminder on the 25th if nothing was uploaded.

## 4. Out of scope (will NOT build in version 1)
- Payments or invoicing.
- A mobile app.
- AI reading or categorizing the documents.
- Chat between client and bookkeeper.

## 5. Data and permissions
- Tables: companies, users, documents, assignments.
- A client can only read and write rows for their own company.
- A bookkeeper can only read companies assigned to them.
- Files are private. No public links.

## 6. Acceptance tests (how we know each feature works)
1. Log in as Client A. Cannot see Client B's files, even by editing the URL.
2. Upload a 10 MB PDF. It appears in the right month.
3. Bookkeeper with two assigned clients sees exactly two.
4. Reminder email arrives for a client with no uploads.

## 7. Tech choices (fill in or ask the AI to propose)
Builder: [Lovable / Claude Code / ...]
Hosting, database, email provider: [...]

## 8. Ideas for later
- AI categorizing receipts.
- Integration with our accounting software.

You do not need to write this alone. Paste your rough notes into Claude or ChatGPT and ask it to turn them into this structure, then ask it what you have missed. It will usually find edge cases you had not considered: what happens when a client has two companies, when a bookkeeper leaves, when someone uploads the wrong file. Decide those now. They are cheap on paper and expensive in code.

Turning the PRD into working software

Once the PRD exists, the build becomes a loop instead of a conversation that wanders.

Step 1: Ask for a plan, not code

Give the tool your PRD and ask it to propose a plan and a numbered task list. Do not let it build yet. In Claude Code this is literally a mode: plan mode lets it read and propose without changing anything. Lovable and others have a chat or plan mode that does the same. Anthropic's own recommended workflow is explore, then plan, then implement, then commit.

Isenberg and Ras Mic go one step further: have Claude Code interview you with its Ask User Question tool, so you are forced to make the decisions about screens, trade-offs and constraints before anything is built. If the AI asks a question you cannot answer, that is a gap in your PRD. Fix the document, not just the chat.

Step 2: Make each task small and testable

A good task list has steps like "create the companies and users tables with these permissions" and "build the upload page for clients," each with a test from your PRD attached. A bad one has "build the backend." If a task cannot be checked by clicking through the app in a few minutes, split it.

Step 3: One task at a time, then check

Let the AI do one task. Then test it yourself against the acceptance test. Lemkin's advice from his guide is blunt: verify every claim the agent makes. If it says the permissions work, log in as the other client and check. Agents report success they have not achieved more often than you would like. (For what happens when you don't check, read how an AI agent deleted a production database.)

Step 4: Save a checkpoint after every working step

Commit in Git, or use your builder's version history, every time a task passes. Addy Osmani, whose essay on the 70% problem is one of the most shared pieces on AI coding, recommends exactly this: frequent commits, so you always have a known good state.

Step 5: Fresh chat for each feature

Long conversations get confused. The AI loses track of earlier decisions and starts contradicting them. Start a new chat for each feature and point it at the PRD again. Keep a rules file the tool always reads: CLAUDE.md in Claude Code, a rules file in Cursor, project knowledge in Lovable. Put your PRD's key decisions there.

Step 6: When it spirals, revert

This is the rule people break most. When a fix creates a new bug, and the fix for that creates another, stop. Go back to the last checkpoint that worked and try the task again with a clearer instruction. Clicking "try to fix" ten more times burns credits and usually leaves the code worse. Osmani calls this the "two steps back" pattern, and the cure is reverting, not persisting.

What this looks like in practice

For the accounting portal above, a realistic plan is one evening on the PRD, a few evenings building the core features one at a time, and then the long part: testing permissions with fake clients, handling the odd uploads, setting up email, deploying properly. Lemkin's month-per-app estimate is a fair guide for anything clients will log into.

That is not a reason not to do it. A well-planned prototype is the best way we know to find out whether an idea is good. It is a reason to plan, because the planning is what keeps a month from turning into a quarter.

Where we come in

We work the same way, because it works. Every product we build starts with the questions in this template: who is it for, what does it do, what will it not do, who can see what. The difference is the kind of product we usually end up writing the PRD for.

Most firms start with an internal tool, like the portal above. That is automation, and it is worth doing. But it is the floor. Every competitor can build the same portal. The bigger opportunity is usually a product your clients would pay for that you could not offer a year ago. We figure that out with you, build a working prototype before any money changes hands, then build the real thing for one fixed fee and stay on as product lead, paid on what it earns.

If you have a PRD half-written and want a second opinion on whether it is the right thing to build, book a call. Bring the document.