PRD template for AI app builders: how to explain your app so Lovable, Bolt or Cursor builds the right thing

A PRD template for AI app builders is a short written description of your app, covering the problem, the users, the screens, the data, the rules and what the first version includes, that you give to Lovable, Bolt, Cursor, Claude Code or ChatGPT before asking it to build anything. AI tools build what you describe and guess the rest. A one-line prompt leaves almost everything to guesswork; a two-page PRD leaves very little. Below is a template you can copy, a filled-in example, and a way to feed it to the AI in stages so it builds the right thing.

Quick answer. Write ten short sections before you prompt: problem, users and roles, core user stories, screens, data and fields, business rules and edge cases, integrations, non-goals, first release scope, and acceptance checks. Keep it to two or three pages in plain language. Save it as a Markdown file, then build in stages: data and roles first, then one user story at a time, checking each stage against the acceptance checks before moving on. The template is in the code block below; copy it as it is.

Why AI app builders build the wrong thing without a PRD

I am a backend engineer, and most of my work starts with a client describing an app they can picture clearly in their head. The trouble is that the picture lives only in their head. When that description goes to an AI builder as a single prompt, the AI does not stop to ask questions. It fills every gap with the most common pattern it has seen, and it does so confidently.

Take "build a fee tracker for my tuition classes". The AI has to decide, without asking you:

• Who logs in: the owner only, or staff and parents too?
• Are fees monthly, quarterly or per course?
• Can a parent pay part of a fee?
• What happens to future fees when a student leaves mid-term?
• Can a payment be deleted, and by whom?
• Do receipt numbers need to run in sequence with no gaps?

Each of those has a common default, and the default is often wrong for your business. Worse, the result looks finished. The screens are tidy, the buttons work, and the wrong assumptions sit inside the database and the code where you will not see them until a real parent pays twice or a staff member deletes a payment to "fix" a mistake.

The same thing happens with human developers, which is why this is also an answer to how to write requirements for a software project in general. Send three developers a two-line idea and you get three quotes for three different apps. A written PRD makes the quotes comparable and the result checkable.

There is a second, quieter problem. When you prompt an AI with a giant paragraph, then correct it with another paragraph, then another, the instructions start to contradict each other. The AI fixes one thing and breaks another, because nothing written down says which version is correct. A PRD is that written-down version. When the AI drifts, you point it back at the document.

What goes into a PRD for AI, and what does not

A product requirements document template for a large company can run to dozens of pages with market analysis, personas and success metrics. You do not need that. A PRD template for vibe coding has one job: remove the guesses that cause the most damage. These are the ten sections that do that, and why each one matters.

What to leave out: technology choices you do not understand, design adjectives ("modern, clean, beautiful"), and long descriptions of features planned for next year. If you are not technical, do not pick a database or framework in the PRD just because a video recommended it. Describe what the app must do, and let the tool or developer choose how, unless you have a real reason such as a system you already run.

The PRD template for AI (copy this)

Copy everything in the block below into a new file called PRD.md, replace the bracketed text, and delete any hint lines you do not need. Plain language is fine. Short sentences are better than long ones.

# PRD: [App name]

Version: [1.0]  Date: [date]  Owner: [your name]

## 1. Problem
[Two to four sentences. Who has the problem, what they do today
(spreadsheet, WhatsApp, paper), and what goes wrong with that.]

## 2. Users and roles
| Role | Who they are | Can do | Cannot do |
| --- | --- | --- | --- |
| [Owner] | [...] | [...] | [...] |
| [Staff] | [...] | [...] | [...] |

## 3. Core user stories
- As a [role], I want to [action], so that [reason].
- [Keep this to the 5 to 10 stories the first version exists for.]

## 4. Screens
| Screen | Who sees it | What it shows | Actions on it |
| --- | --- | --- | --- |
| [Login] | [All] | [...] | [...] |

## 5. Data and fields
### [Record name, e.g. Customer]
- [field]: [type: text, number, date, money, yes/no, choice of ...] [required? unique?]
- Belongs to: [other record]

## 6. Business rules and edge cases
- [Rule written as a sentence. "A payment can never be deleted, only reversed by the owner with a reason."]
- [What happens when: someone cancels, pays twice, pays part, leaves,
  edits the same record as someone else, enters a duplicate, makes a mistake.]

## 7. Integrations
- [Service]: [what it is used for] [in first release? yes/no]

## 8. Non-goals (not in this version)
- [Feature you will NOT build yet, and why.]

## 9. First release scope
- In: [list of user stories or screens]
- Later: [list]
- Cut: [ideas dropped for now]

## 10. Acceptance checks
- [ ] [Check written so a non-developer can test it:
      "Recording a payment of 500 against a fee of 2,000 leaves 1,500 due."]

## Open questions
- [Anything you have not decided yet. The AI must ask, not guess.]

The "Open questions" section at the end is worth keeping even though it is not one of the ten. Telling the AI "these are undecided, ask me before assuming" is one of the most useful sentences you can give it.

How to write a PRD for AI without being technical

Problem. Describe today, not the app. "Fees are tracked in a register and an Excel sheet. Parents ask on WhatsApp how much they owe, and the front desk has to check both" is far more useful than "a modern fee management platform".

Users and roles. List every kind of person who will log in. For each, write one line on what they can do and, more importantly, what they cannot. "Staff can record payments but cannot delete them or change fee amounts" prevents a whole class of problems.

User stories. Use the "As a ..., I want to ..., so that ..." format. It feels formal, but it forces you to name who is acting and why, which the AI needs. If you have more than ten for a first version, you are describing version three.

Screens. A list is enough. You do not need drawings, although a photo of a sketch on paper helps if your tool accepts images. For each screen, say what is on it and what each button does.

Data and fields. Think of the forms and registers you use today. Each register is usually a record, and each column is a field. Say which fields are required and which must be unique, such as a phone number or a receipt number.

Business rules and edge cases. This is the section that separates an app that works from one that only demos well. Go through a bad day: someone pays twice, enters the wrong amount, leaves halfway, or two staff members work on the same record at once. Write what should happen in each case.

Integrations. Name the outside services and what each is for. If an integration is not in the first release, say so, or the AI may build a button that looks connected and does nothing.

Non-goals. AI builders are eager. Writing "no parent login in this version" stops them adding one.

First release scope. Split into in, later and cut. Anything you could do by hand for your first twenty users can usually wait.

Acceptance checks. Write them as tests a non-developer can run with real numbers. These are how you check the AI's work, so make them specific.

A filled-in example: a tuition class fee tracker

This is a fictional example, not a client project, kept short on purpose. It shows the level of detail that is enough for an AI builder to get most decisions right the first time.

# PRD: FeeBook (fictional example)

Version: 1.0  Owner: Class owner

## 1. Problem
A tuition class with about 120 students in 6 batches tracks fees in a
paper register and an Excel sheet. Parents ask on WhatsApp how much is
due. Staff check both records, which often disagree. Receipts are
handwritten and numbers are sometimes skipped or repeated.

## 2. Users and roles
| Role | Who | Can do | Cannot do |
| --- | --- | --- | --- |
| Owner | Class owner | Everything; set fees and discounts; reverse payments | n/a |
| Staff | Front desk (2 people) | Add students, record payments, print receipts, view dues | Delete or reverse payments, change fees or discounts |

## 3. Core user stories
- As staff, I want to add a student to a batch, so their monthly fees start.
- As staff, I want to record a cash or UPI payment, so the due amount updates.
- As staff, I want to print or share a receipt as a PDF, so the parent has proof.
- As the owner, I want a list of overdue students per batch, so we can follow up.
- As the owner, I want to reverse a wrong payment with a reason, so records stay honest.
- As the owner, I want a monthly collection report, so I know what came in.

## 4. Screens
| Screen | Who | Shows | Actions |
| --- | --- | --- | --- |
| Login | All | Email, password | Log in, reset password |
| Dashboard | All | Collected this month, total overdue, overdue count per batch | Open a batch |
| Students | All | List with batch, phone, amount due; search | Add, edit, open |
| Student detail | All | Fee dues by month, payments, receipts | Record payment |
| Record payment | Staff, Owner | Amount, method (cash/UPI), date, note | Save, print receipt |
| Batches and fees | Owner | Batches with monthly fee | Add, edit fee (applies to future months only) |
| Reports | Owner | Collection by month and method; overdue list | Export to Excel |
| Users | Owner | Staff accounts | Add, deactivate |

## 5. Data and fields
### Student
- name: text, required
- parent phone: text, required, unique per student
- batch: choice of batches, required
- join date: date, required
- leave date: date, optional
- discount: money per month, optional, owner only

### Batch
- name: text, required, unique
- monthly fee: money, required

### Fee due (one per student per month)
- student, month, amount, status: due / part paid / paid / cancelled

### Payment
- student, amount (money, more than 0), method (cash or UPI),
  date, note, recorded by (user), reversed (yes/no), reverse reason

### Receipt
- number: sequential, unique, never reused, no gaps
- payment it belongs to

## 6. Business rules and edge cases
- Fee dues are created on the 1st of each month for every active student.
- A fee is overdue 10 days after the 1st if not fully paid.
- Part payments are allowed; they pay off the oldest due month first.
- A payment can never be deleted. Only the owner can reverse it, with a
  reason. The receipt stays, marked "reversed".
- Receipt numbers never repeat, even if two staff save a payment at the
  same moment.
- If the same amount is recorded for the same student twice within
  10 minutes, warn before saving.
- When a student leaves, dues after the leave date are cancelled; dues
  before it stay.
- Changing a batch fee affects future months only, never past dues.
- Discounts reduce each new monthly due; only the owner can set them.

## 7. Integrations
- PDF receipts: in first release.
- Excel export of reports: in first release.
- WhatsApp reminders: later, not now.
- Online payment gateway: not now; UPI is recorded by hand.

## 8. Non-goals
- No parent login.
- No attendance, timetable or marks.
- No online payments.
- No mobile app; the web app must work on a phone browser.

## 9. First release scope
- In: stories 1 to 6, all screens above.
- Later: WhatsApp reminders, parent view link, sibling discounts.
- Cut: SMS, multiple branches.

## 10. Acceptance checks
- [ ] A student who joins on the 15th gets a full due for that month
      (owner can adjust with a discount).
- [ ] Monthly fee 2,000, payment 500: student shows 1,500 due, status part paid.
- [ ] Payment of 3,000 when two months of 2,000 are due: oldest month
      paid, newer month shows 1,000 due.
- [ ] Staff cannot see a reverse button; owner can, and must enter a reason.
- [ ] Two payments saved at the same time get different receipt numbers.
- [ ] Changing a batch fee from 2,000 to 2,500 does not change last month's due.
- [ ] Overdue list on the 11th shows every student with an unpaid due.

## Open questions
- Should a student who joins after the 20th pay half for that month?

Notice how little of it is technical. There is no framework, no database name and no design language. What there is: who can do what, what each record holds, and what happens when something goes wrong. The rules about receipt numbers and two staff saving at once are exactly the kind of thing AI-generated apps get wrong, because a demo with one user never exposes them.

How to feed your PRD to Lovable, Bolt, Cursor or Claude Code in stages

The biggest mistake after writing a PRD is pasting the whole thing in one prompt and saying "build this". You will get something, but the tool tries to do everything at once, and the details in sections 6 and 10 are the first to be dropped. Build in stages instead, and check each one.

The exact features of each tool change often, so this is the general approach rather than a click-by-click guide. Check your tool's own documentation for where project instructions live.

1. Put the PRD where the tool can see it. In code editors and terminal agents such as Cursor or Claude Code, save PRD.md in the project folder and tell the agent to read it. Claude Code also reads a CLAUDE.md file for standing project instructions, and other tools have their own equivalent; a short line there saying "follow PRD.md; ask before assuming anything in Open questions" is worth adding. In browser builders such as Lovable or Bolt, paste the relevant sections into the chat for each stage, or add them wherever your tool keeps project knowledge.
2. Ask for a plan first, not code. Ask the tool to read the PRD and list the data tables, the roles and the screens it intends to build, and to list anything unclear. If your tool has a mode for discussing a change before making it, use it here. Correct the plan before any code exists.
3. Stage one: data and roles. Build login, roles and the data from section 5, with the permissions from section 2. Nothing else. Check that staff really cannot do what the PRD says they cannot do, by logging in as staff.
4. Stage two onwards: one user story at a time. Pick the most important story, build it, then run its acceptance checks yourself. Only then move to the next. Each prompt names the PRD section it implements.
5. Rules and edge cases as their own stage. After the main stories work, go through section 6 one rule at a time. Ask the tool how each rule is enforced, and where, so you know it is not only hidden in the screen.
6. Integrations last. Payments, email and messaging come after the core works, each as its own stage.

A stage prompt can be as short as this:

Read PRD.md. Implement user story 2 (staff records a cash or UPI
payment) only. Follow the data in section 5 and rules 3, 4 and 5 in
section 6. Do not change anything unrelated. When done, list which
acceptance checks in section 10 this covers and how I can test each one.

When something is wrong, refer to the document rather than describing the fix from scratch: "This breaks rule 4 in section 6: staff can delete payments. Fix only that." It keeps the AI anchored, and it keeps your PRD as the single source of truth. When you change your mind, change the PRD first, then ask for the change.

Common mistakes when writing a PRD for AI

• Describing the look instead of the behaviour. "Clean and modern" tells the AI nothing it would not do anyway. "Overdue students in red at the top" does.
• No roles. If you do not say who cannot do something, assume everyone can.
• Rules only in your head. "Obviously payments cannot be deleted" is obvious to you. Write it down.
• Too big a first version. Ten core stories is a lot. Five is often better.
• No non-goals. Without them, the AI adds features, and every extra feature is more to check.
• Vague acceptance checks. "Payments work" cannot be tested. "Paying 500 against 2,000 leaves 1,500 due" can.
• Trusting the screen. A rule shown on screen is not a rule enforced. If a staff member can skip it by using the browser differently, it is not enforced. This is where AI-built apps most often fail.
• Letting the PRD go stale. Once the code and the document disagree, the AI has nothing reliable to follow.

A quick check before you start building

• I can explain the problem in four sentences without naming a feature.
• Every role has a "cannot do" column.
• I have ten or fewer user stories for the first release.
• Every screen is listed with its actions.
• Every record has its fields, and I have marked required and unique ones.
• I have written what happens for cancellations, duplicates, part payments, mistakes and two people editing at once.
• Every integration says whether it is in the first release.
• Non-goals are written down.
• Every core story has at least one acceptance check with real numbers.
• Open questions are listed, and the AI is told to ask rather than guess.

Is this different from a PRD template for Claude Code?

Not in content. A PRD template for Claude Code, Cursor or any agent that works inside your project files is the same document. The difference is how you use it: agents that read files can keep the PRD open as a reference for every task, so you can point them at sections by number, and you should still build in stages. Browser builders need you to bring the relevant section into each conversation. Either way, the document is what keeps the result tied to what you meant.

When to get help

Writing a PRD yourself with this template works well when you know your business process and have the patience to think through the bad days. Get help when:

• You cannot fill in the sections. If you are stuck on roles, rules or scope, that is normal: the questions are the hard part. I turn app ideas into a written plan: I ask the questions, write the PRD, and then either build it or hand it to you to take to an AI builder or another developer.
• The AI-built app is close but keeps breaking. Fixes that break something else usually mean the backend structure underneath is wrong. My vibe coding cleanup service reads the generated code, fixes the data and rules, and tells you honestly what is worth keeping.
• You are about to launch with real users or real money. Before you do, go through my vibe coding security checklist, and if your app was built in Lovable, my Lovable app to production service covers authentication, database rules, payments and deployment.

The template above costs nothing to use, and even if you hire someone later, a filled-in PRD makes every conversation shorter and every quote more accurate. Start with the problem section today; it is the one most people skip, and the one that shapes everything else.