PRD Template for AI Apps: Write It Before You Prompt

1. What a PRD is and why to create one

A PRD describes what an app should do, who it's for and how you'll know it's finished. It doesn't cover how to code the app or what architecture it should have. That's the difference from a specific prompt, which tells the AI what to do right now.

If you start with a prompt, the AI may make up things you didn't say. Even as you steer it step by step, your decisions stay in the chat history. That history is long, full of dead ends and will probably stay behind when you move to another tool, as How to Build an App with AI explains. A PRD, on the other hand, is a separate document that you, another person or even a different AI tool can read.

2. How long should a PRD be?

A PRD for an AI tool fits on one or two pages. For a person, it should be quick to read and understand. If you don't know something yet, write it down as an open question. A document for a development team will contain more because it also helps clarify communication between people.

3. PRD template to copy

This PRD template has eleven parts. If you don't need some of them, delete them.

# <App name>: Product requirements

## 1. Summary
One sentence: what the app does and for whom.

## 2. Problem
What bothers users today and how they cope without the app.

## 3. Users and roles
- Who uses the app:
- Who manages it:
- What each role can do:

## 4. Main scenarios
1. A user <does something> and <what happens>.
2.
3.

## 5. Features in version one
-

## 6. Out of scope for version one
-

## 7. Data
- What the app stores:
- Personal data:

## 8. Services and technology
- Sign-in, database, payments, email:
- Technology: <specific, or let the AI choose>

## 9. Look and feel
- Devices:
- Languages:
- Style:

## 10. Done when
- [ ]
- [ ]

## 11. Rules for the AI
- Before a larger change, the AI proposes a plan and waits for approval.
- The AI doesn't add libraries or services without approval and a license check.
- Secret keys stay out of the code and out of this document.
- After any change in how the app behaves, the AI updates this document.

4. Product requirements document example

This product requirements document example describes a simple app for booking meeting rooms at a company. Notice that part 6 rules out things the AI might otherwise add on its own, such as payments or a mobile app.

# Room Booking: Product requirements

## 1. Summary
A web app where company employees book meeting rooms.

## 2. Problem
Bookings are arranged by email and kept in an Excel spreadsheet, so they sometimes overlap.

## 3. Users and roles
- Who uses the app: employees, about 50 people
- Who manages it: the office team
- What each role can do: employees manage their own bookings, the office team manages all bookings and the room list

## 4. Main scenarios
1. An employee picks a day and sees the free times for every room.
2. An employee books a free time and gets a confirmation email.
3. An employee cancels their booking and the time becomes free again.

## 5. Features in version one
- Sign-in with a company email
- Daily room overview
- Creating and canceling bookings
- Managing the room list

## 6. Out of scope for version one
- Payments
- Mobile app
- Recurring bookings
- Company calendar integration

## 7. Data
- What the app stores: rooms, bookings, users
- Personal data: name and company email

## 8. Services and technology
- Sign-in, database, email: whatever the tool offers
- Technology: let the AI choose

## 9. Look and feel
- Devices: computer and phone, in the browser
- Languages: English
- Style: simple and light

## 10. Done when
- [ ] Two bookings of the same room can't overlap, even when submitted at the same time.
- [ ] An employee can't cancel someone else's booking.
- [ ] The confirmation email arrives within a minute.

## 11. Rules for the AI
- Before a larger change, the AI proposes a plan and waits for approval.
- The AI doesn't add libraries or services without approval and a license check.
- Secret keys stay out of the code and out of this document.
- After any change in how the app behaves, the AI updates this document.

5. How to give your PRD to Lovable, Cursor and other AI tools

Save your PRD for the AI tool so it's available in every session, not just in the first message. The location differs from tool to tool. Also keep a backup of the document outside the AI tool.

1. 1

   Save the PRD where the tool reads it

   In Lovable, paste it into Project settings → Instructions. According to Lovable's docs, the limit there is 10,000 characters and the text applies to every message. In Cursor, save it in the project as docs/PRD.md and add a line to AGENTS.md in the project root telling the agent to read it. Cursor's docs also cover more detailed rules in the .cursor/rules folder.

2. 2

   Have the AI review the spec

   Use your first prompt to have the AI review the document. The AI lists what's unclear and proposes a step-by-step plan. You check the plan and correct the document as needed. There's a sample prompt below.

3. 3

   Build one scenario at a time

   Ask for the first scenario from part 4, try it out and only then move on to the next. A bug is easier to find in one scenario than in a whole app.

4. 4

   Check against the "Done when" part

   After each step, go through the conditions in part 10. Before your users see the changes, try them on a staging environment if you have one.

Read PRD.md. Don't write any code yet.
Tell me what's unclear or contradictory in the spec
and propose a plan for version one with the individual steps written out.

6. How to keep a PRD up to date

A PRD stays up to date when you update it every time the app's behavior changes. Say you decide in the chat that bookings can only be canceled a day in advance. If that doesn't go in the PRD, the next session or a different tool won't know about it. The rule in part 11 hands this over to the AI, but always check the change.

The PRD itself describes how the app should work today, but it has no history of what changed when. So keep the change history separately: give every released change a version number and describe it in the release notes. That's how you'll find out which version started behaving differently.

7. Link your PRD to the app in AboutTheApp

Your PRD should be easy to find without access to the AI tool, so link to it right from your app in AboutTheApp. In the product editor, click Add resource, pick the Analysis & Planning category and paste the address of your document. You can also save a link to the Lovable or Cursor project under AI & Vibecoding.

Choose Private for the link if the spec isn't publicly available. Private links are visible to signed-in team members and anyone with the unlock code. Record changes for each version through the version history icon on the app card or from CI/CD. A new version stays private until you publish it. The About page then keeps the spec, the AI tool project, the repository and the version history together, as Project Links describes.

Frequently asked questions