A PRD (product requirements document) tells whoever builds an app what to build. For an AI coding tool such as Cursor, Claude Code or Lovable, it needs to go further than a PRD for a human team: the AI won't come back with questions, so every gap gets filled with a guess.
Below is the 10-section template SpecWise uses. Copy it into a file called SPEC.md, fill in each section, and give it to your coding tool before it writes any code.
The template
# [App name] - Product Requirements Document
## 1) Summary
[2-3 sentences: what it is, who it's for, the one thing it must do well.]
- Assumption: [where data lives: on the device, or on a server with accounts]
- Assumption: [the core rule, stated precisely]
- Assumption: [limits: max items, max lengths]
- Assumption: [platform: phone, desktop, or both]
## 2) Tech Stack
- **Framework** → [choice] → [why]
- **Storage** → [choice] → [why]
- **Auth** → [choice, or None] → [why]
- **Styling** → [choice] → [why]
- **Deployment** → [choice] → [why]
## 3) Users & Screens
| Screen | Reached from | Shows | Empty / loading / error | Back goes to |
|---|---|---|---|---|
| [Home] | [App launch] | [...] | [exact empty-state text] | [None] |
## 4) Data Model & Logic
[Each record type with fields, types and limits.]
[Each rule written so it can be checked, with one worked example.]
## 5) External Services
[Each outside service, what it's used for, and what happens if it's down. Or: None.]
## 6) Core Features
### 6.1 [Feature]
- User does: [...]
- App does: [...]
- Exact text: `[button label]`, `[error message]`
- When it fails: [...]
## 7) UI/UX
[Layout, colors, type, spacing, and how it behaves on a phone.]
## 8) Infrastructure Notes
[Environment variables, hosting setup, anything needed to run it.]
## 9) Out of Scope (V1)
- [Thing you are not building yet]
## 10) Success Criteria
- [ ] [A check a person or a test can confirm]
Tips for filling it in
Write assumptions as decisions. "Assumption: no accounts; data stays on the device" is a decision. "Maybe add accounts later" is not, so move it to Out of Scope.
Give every screen its empty state. The first thing a new user sees is an empty screen. Write the exact words it shows and the button that gets them started.
Use worked examples for rules. "Late fee is 2% per week" can be read several ways. "Invoice due March 1, paid March 16: two full weeks late, so the fee is 4%" can't.
Quote exact text. Put button labels and error messages in backticks. AI tools copy quoted text exactly, and make up their own wording when there is none.
Keep version 1 small. Each item in Out of Scope is a feature the tool won't build on its own initiative, and a build you are more likely to finish.
Skip the blank page
Filling in this template well takes a few hours. SpecWise fills in all ten sections from a one-sentence idea, including the assumptions, screen states, worked examples and exact text. See real examples, or read the full guide to writing a spec.