Free PRD template for AI app builders
A PRD (product requirements document) tells your AI builder what to build, for whom, and in which order. Fill in the ten questions below and copy the result into Lovable, Bolt, v0, Replit, Cursor or Claude Code. It's free, works in your browser, and needs no account.
Your PRD
# PRD: PawStep ## Summary A booking app for dog walkers. Dog owners find a walker nearby, book a walk and pay online. ## Who it's for - Dog owners: find a walker, book a walk, pay, and get a photo after the walk. - Walkers: set their area and price, see today's walks, and get paid per walk. ## The problem Owners arrange walks by text and pay in cash, so walks get forgotten and walkers chase payments. ## Features in the first version 1. Owners and walkers can create an account 2. Walkers can set up a profile with their area and price 3. Owners can find a walker nearby 4. Owners can book a walk and pay for it 5. Walkers see today's walks 6. Walkers send a photo after each walk ## Not in this version - Ratings and reviews - Repeat weekly bookings - A live map of the walk ## Data - Users with their role (owner or walker) - Walker profiles: area, price, a short text - Bookings: owner, walker, date, time, status - Payments: booking, amount, status ## Accounts and access Sign in with email. Owners only see their own bookings. Walkers only see bookings made with them. Nobody can see another person's payment details. ## Payments Owners pay by card when they book, through a payment provider like Stripe. PawStep keeps a small fee and pays the walker after the walk. ## Done when - [ ] An owner can sign up, find a walker and book a walk - [ ] The walker sees that walk in their list for the day - [ ] A test payment goes through, and no card numbers are stored in the app - [ ] One owner can't see another owner's bookings ## How to build this Instructions for Lovable: - Build one feature at a time, in the order of the list above. - Before you start a feature, say in one or two sentences what you're going to build. - Don't change features that already work, and don't build anything from "Not in this version". - If something isn't decided in this document, ask before you guess. - After each feature, tell me how to test it, and wait until I say it works.
Paste it as your first message, then ask for the first feature only.
What goes in a PRD for an AI builder
A classic PRD is written for a team of developers and can run to twenty pages. An AI builder needs something shorter and stricter: what to build, in which order, and what to leave alone. This template keeps the six parts that matter.
| Part | Why it matters |
|---|---|
| Summary and who it's for | The AI builds different screens for a walker than for an owner. Say who does what. |
| Features, in build order | Sign-up before bookings, bookings before payments. The order prevents rebuilds. |
| Not in this version | AI builders like to add extras. This list tells them what to leave alone. |
| Data, accounts and access | Who can see what is the part that's hardest to fix later, and the easiest to forget. |
| Payments | Money needs care. Decide who pays, for what, and with which provider before you build. |
| Done when | A short checklist per version, so you and the AI agree on what "finished" means. |
PRD example: a product requirements document for a booking app
The template above starts filled in with a complete PRD for PawStep, a booking app for dog walkers. It shows what a good product requirements document looks like at the size an AI builder can follow: two kinds of users, six features in build order, three ideas saved for later, the data, who can see what, payments and a short checklist.
Read it once before you write your own. Notice how each feature is one line someone can build and test, and how "Not in this version" keeps the AI from adding extras. Then click "Clear and write my own".
How to write a product requirements document
- Start with one sentence. What the app does and for whom. If you can't say it in one sentence, the app is still too big for a first version.
- Name the users. Each kind of user and what they do. An owner and a walker need different screens, so the AI needs to know both.
- List features in build order. One feature per line, starting with sign-up if people need an account. Build what other features depend on first.
- Write down what's not in this version. Ideas you're saving for later. This is the part most PRDs skip, and the part that saves the most rework.
- Decide data, access and payments. What the app stores, who can see what, and who pays for what. These are the hardest to change later.
- End with "done when". Three to five checks that tell you the first version works. Test each one before you call it finished.
How to use your PRD
- Fill in the questions above. Short answers are fine, and you can leave a part open if you haven't decided.
- Copy the PRD and paste it as the first message in Lovable, Bolt, v0, Replit, Cursor or Claude Code.
- Ask for the first feature only. Don't ask for the whole app in one prompt.
- Test it. When it works, ask for the next feature on the list.
More on this in Do you need a PRD for Lovable or Bolt? and How to write prompts for AI app builders.
Frequently asked questions
What is a product requirements document (PRD)?
A PRD, or product requirements document, describes what a product should do before anyone builds it: who it's for, the problem it solves, the features in the first version and how you'll know it works. With AI builders it's the plan the AI follows.
Do I need a PRD for Lovable, Bolt or Cursor?
You don't need one to start, but it saves a lot of rework. Without a plan the AI guesses what you mean, and you spend prompts and credits undoing the guesses. A short PRD with features in build order is enough.
How long should a PRD for an AI builder be?
One page is plenty for a first version. Five to ten features, a few lines on data and accounts, and a short checklist. Long documents get skimmed, by people and by AI.
How do I use this PRD in my AI builder?
Copy it and paste it as your first message, then ask for the first feature only. Don't ask for the whole app at once. Build one feature, test it, and then ask for the next one from the list.
Can I use this PRD template in Google Docs, Notion or Word?
Yes. Click Copy and paste it into a Google Doc, a Notion page or a Word file, or click Download .md to keep it as a file. It's plain Markdown, so the headings and lists stay intact.
Is there a PRD template for a mobile app?
This template works for web and mobile apps. For a mobile app, say in the summary whether it's for iPhone, Android or both, and describe the main screens in each feature.
Is this PRD template really free?
Yes. It runs in your browser, there's no account and nothing you type is sent to us or saved.