Is Major Cooked? Free AI risk score + roast for your college major
Solo Era solo activities, solo maxxing, sidequests, challenge
Keepsake Project Management, Freelancers, DesignersProduct requirements document template: a copyable PRD for apps, with an example
A product requirements document (PRD) is a short written plan that says what you are building, for whom, why, and how you will know it works, without saying how to code it. A useful app PRD has a problem statement, a user, goals and non-goals, numbered requirements with acceptance checks, open questions and success measures. Copy the template below, fill it in, then paste it into your AI coding tool as the source for the build prompt.
What is a product requirements document?
A PRD describes the product before it exists. It answers what the product should do and why, and leaves how to the builder. For a team, it keeps designers, engineers and stakeholders agreeing on the same thing. For a solo founder using an AI coding agent, it does something just as useful: it forces you to decide before you start, and it gives the agent a written source of truth that does not drift between chats.
People also search for an “app specification template” or a “software requirements document”. In practice these overlap. The table shows where each one sits so you can write only the ones you need.
| Document | Answers | Length | Who reads it |
|---|---|---|---|
| Idea brief | Is this worth doing, and for whom? | One page | You, a possible partner, the board |
| PRD | What should the product do, and how do we know it works? | 1 to 4 pages | Builders, designers, you, an AI agent |
| App specification (technical spec) | What screens, data and rules does it contain, exactly? | 2 to 6 pages | Whoever writes the code |
| Build prompt | What do I tell the coding agent to do in this session? | Under a page | The AI agent |
For a small app, one document can cover the PRD and spec sections, and the build prompt is a slice of it. The guide to validating an app idea comes before the PRD, because a PRD for an idea nobody wants is only a tidy way to waste a month.
How do you write a PRD?
Write it in this order. The order matters because later sections depend on earlier ones.
- Problem and user. Name one person and the last time they had the problem. If you validated the idea, copy the words your interviewees used.
- Goals and non-goals. Goals are the two or three outcomes that define success. Non-goals are what you will not build in this version. Non-goals matter more than goals, since an AI agent and a human team both add features unless told to stop.
- The core flow. Describe the one path a user takes from start to the result they came for, in numbered steps.
- Requirements. One line each, numbered, with a priority: must, should, later. Each must-have gets an acceptance check, a sentence a stranger could use to test it.
- Data and rules. The things the app stores and the rules about them: who can see what, what is required, what is limited.
- Success measures. One or two numbers you can observe within a few weeks. Not “users love it”.
- Open questions and risks. What you do not know yet. Writing these down is how you avoid pretending.
Cut anything that does not change what gets built. A PRD that nobody finishes reading does not get used. If a section is hard to fill in, that is the part to research next; the guide to market research for an app idea and the MVP scoping guide help with the hard ones.
What does a PRD template for an app look like?
Copy this into a document or a file called PRD.md in your project folder. Replace everything in square brackets. Delete sections you do not need rather than leaving them empty.
# [Product name]: Product requirements Status: draft | Owner: [name] | Last updated: [date] ## 1. Summary For [specific person] who [has this problem], [Product name] [does one thing] so that [outcome]. ## 2. Problem - Who has it: [role, situation] - Last time it happened: [a specific story from an interview] - What they do today: [workaround, tool, nothing] - What that costs them: [time, money, stress, in their words] - Evidence so far: [interviews held, waitlist, links] ## 3. Goals 1. [Outcome 1, written so you can tell whether it happened] 2. [Outcome 2] ## 4. Non-goals (version 1) - [Feature or audience you will NOT serve yet] - [Platform you will NOT build: native apps, admin panel, etc.] - [Integration you will NOT build] ## 5. Users and scenarios - Primary user: [description] - Scenario: [User] wants to [goal]. They [start action]. They get [result]. ## 6. Core flow 1. User [opens / lands on ...] 2. User [enters ...] 3. System [does ...] 4. User sees [result] 5. User can [share / save / repeat] ## 7. Requirements | ID | Requirement | Priority | Acceptance check | | R1 | [The user can ...] | Must | [Given X, when Y, then Z] | | R2 | [The system ...] | Must | [...] | | R3 | [...] | Should | [...] | | R4 | [...] | Later | [...] | ## 8. Data and rules - Things stored: [list: field, type, required?, limit] - Who can read / write what: [rules] - Limits: [length, rate, size] - Personal data held: [none / what, and why] ## 9. Screens - [Screen name]: [purpose and main elements] - [Screen name]: [...] ## 10. Success measures - [Measure 1, e.g. number of people who complete the core flow in the first month] - [Measure 2, e.g. number who come back within seven days] - Decision rule: if [measure] is below [number] after [time], we [change / stop]. ## 11. Risks and open questions - [Assumption that would sink the idea, and how to test it] - [Question I have not answered] ## 12. Out of scope for the AI agent - Do not add features not listed in section 7. - Do not install new dependencies without asking. - Do not store secrets in code. Use environment variables. - Ask before changing the data model.
Section 12 is not standard in PRD guides. It is there because the reader may be a coding agent, and an agent needs its limits stated.
What does a filled-in PRD look like for a small app?
Here is a completed PRD for an invented small app, so you can see the level of detail. The product and its numbers are made up for illustration and do not describe a real company.
# Handoff: Product requirements Status: draft | Owner: Sam | Last updated: 2026-10-30 ## 1. Summary For pet owners who leave their animals with a friend or sitter, Handoff turns a short form into one shareable page with feeding, medication and vet details, so that the sitter does not need to phone the owner. ## 2. Problem - Who has it: owners who travel a few times a year and use a friend or neighbor as a sitter - Last time it happened: owner left a text message of 40 lines; sitter missed the evening medication - What they do today: a long text message or a note on the fridge - What that costs them: worry while away, calls from the sitter - Evidence so far: 6 owner interviews; 5 had the same story ## 3. Goals 1. An owner can create a complete sheet in under 10 minutes. 2. A sitter can read it on a phone without an account. ## 4. Non-goals (version 1) - No accounts or logins - No payments, no booking of sitters - No native app; web only - No photo gallery or live updates from the sitter ## 5. Users and scenarios - Primary user: owner of one to three pets - Scenario: Owner leaves on Friday. They fill the form on Wednesday, send the link, and the sitter opens it on Saturday morning. ## 6. Core flow 1. Owner opens the site and starts a new sheet 2. Owner adds each pet: name, food, amount, times, medication, quirks 3. Owner adds contacts: own phone, vet, emergency contact 4. System creates a private link 5. Owner copies the link and sends it 6. Sitter opens the link and sees a mobile-friendly page ## 7. Requirements | ID | Requirement | Priority | Acceptance check | | R1 | Owner can add 1 to 3 pets with name, food, amount and times | Must | Given 3 pets, when I save, then the page shows all 3 in order | | R2 | Medication has its own block with dose and time | Must | A medication entry is visually distinct from feeding | | R3 | Page is reachable only through an unguessable link | Must | Changing one character of the link returns not found | | R4 | Page works on a 360 px wide phone screen without sideways scrolling | Must | Checked in a browser at that width | | R5 | Owner can print the page | Should | Print view fits one sheet for one pet | | R6 | Owner can change the sheet later through a second private address | Later | Not in version 1 | ## 8. Data and rules - Stored: sheet (id, created date), pets (name up to 40 chars, food text up to 300), medications (text up to 300), contacts (name, phone) - Read: anyone with the sheet link. Write: only at creation. - Limits: 3 pets per sheet; sheet auto-deleted 60 days after creation - Personal data: owner and vet phone numbers, shown only on the sheet ## 9. Screens - Create: a single long form in four steps - Share: the link and a copy button - Sheet: the read-only page the sitter sees ## 10. Success measures - 10 owners out of 30 invited complete a sheet in the first month - At least 5 sitters say they would not have needed to call - Decision rule: if fewer than 5 owners complete a sheet, stop and talk to owners again. ## 11. Risks and open questions - Do owners trust a stranger site with a vet phone number? Test with a no-phone variant. - Will sitters open a link? Ask the six interviewees. ## 12. Out of scope for the AI agent - Do not add features not listed in section 7. - Do not install new dependencies without asking. - Do not store secrets in code. Use environment variables. - Ask before changing the data model.
Notice what carries the weight: the non-goals, the limits in section 8, and the acceptance checks. Together they leave an agent very little room to invent a different product.
What should an app specification template add?
A PRD says what and why. A specification adds the exact shape of the software. If you plan to hand the work to a developer, or want an AI agent to make fewer guesses, append this block to the PRD.
## Technical specification ### Stack - Front end: [framework] - Back end and database: [service] - Hosting: [service] - Authentication: [none / method] ### Data model | Table | Column | Type | Required | Rule | | [table] | [column] | [text / number / date] | [yes / no] | [length limit, unique, etc.] | ### Routes or screens | Path | Purpose | Who may open it | Data it reads or writes | | [path] | [purpose] | [anyone / owner only] | [tables] | ### Rules and edge cases - When [condition], then [behavior]. - Empty state: [what the user sees with no data] - Error state: [what the user sees when something fails] ### Security basics - Secrets only in environment variables, never in browser code. - Validate every input on the server, with the same limits as the form. - Limit how often one visitor can submit. ### Done means - Every Must requirement has a passing check. - The app runs from a fresh clone with the steps in README. - The checks are written down, one by one, so I can run each myself.
How do you turn a PRD into an AI build prompt?
Do not paste the whole document and say “build this”. Agents do better with a small first slice and the document available as reference. Follow these steps.
- Save the PRD in the project. Put it at docs/PRD.md in the repository so the agent can read it in every session instead of relying on a chat that scrolls away.
- Point the agent to it. In Claude Code, a CLAUDE.md file can import additional files with the @path syntax, so a line like “See @docs/PRD.md for requirements” loads the document alongside your instructions. The guide to writing CLAUDE.md covers what else belongs there.
- Ask for a plan first. Claude Code has a plan mode where the agent reads files and proposes a plan without editing anything until you approve; start it with
claude --permission-mode planor press Shift+Tab (Claude Code docs). See Claude Code plan mode. - Build one requirement slice at a time. Start with R1 and R2, check them yourself against their acceptance lines, then move on.
- Update the PRD when you change your mind. If the code and the document disagree, the agent follows whichever it read last.
Read docs/PRD.md in full before writing code. You are building version 1 of the product described there. Do only requirements R1 and R2 in this session. Do not start R3 or later. First, reply with a plan: the files you will create, the data model you will use, and how you will check each acceptance line. Wait for my approval before writing code. Rules: - Follow section 4 (non-goals) and section 12 strictly. - Keep the stack minimal. Ask before adding a dependency. - After you write the code, run it and tell me exactly how I can check R1 and R2 myself. - If the PRD is ambiguous, ask a question instead of guessing.
The same prompt works in other tools: paste it into Cursor or Lovable as the first message and keep the PRD text in the project or the chat. For a general method on prompts, see how to write an app build prompt, and for the wider idea of writing the spec first, spec-driven development. The free AI Coding Prompt Builder can draft a prompt from a short description.
Every idea posted on the Post your build ideas board already has a generated build prompt. If you are not sure what a good one looks like, open any idea and read its prompt before you write your own.
What mistakes make a PRD useless?
- No non-goals. Everything seems in scope, so everything gets built.
- Requirements without checks. “Fast” and “intuitive” cannot be tested. “Page loads with 3 pets visible” can.
- Describing the solution instead of the need. Write what the user must be able to do, then let the builder choose the how, unless you have a real reason.
- Writing it once and never updating it. A stale PRD misleads people and agents alike.
- Skipping the evidence. If the problem section has no interview story, go and get one before writing the rest.
- Making it long. Four pages that get read beat twenty that do not.
Frequently asked questions
What should a product requirements document include?
A useful app PRD includes a summary, the problem and the user, goals, non-goals, the core flow, numbered requirements with priority and acceptance checks, data and rules, success measures, and open questions. Non-goals and acceptance checks do the most work, because they stop scope creep and make each requirement testable.
How do I write a PRD?
Start with the problem and one named user, then write goals and non-goals, the core flow in numbered steps, and requirements with a priority and an acceptance check each. Add data rules, one or two success measures and a list of open questions. Cut anything that does not change what gets built.
What is the difference between a PRD and an app specification?
A PRD says what the product should do, for whom and why. An app specification adds the exact shape of the software: screens, data model, rules, error states and stack. For a small app you can write one document with both, and the PRD sections come first.
How long should a PRD be?
One to four pages is enough for a small app. If you cannot say what version 1 does in that space, the scope is probably too big. Length is not a measure of quality; the document should be short enough that you and any builder, human or AI, read the whole thing.
Can I use a PRD with an AI coding tool?
Yes. Save the PRD as a file in the project, point the agent at it, and ask for a plan before code. Then build one requirement slice at a time and check each against its acceptance line. State the non-goals clearly, since agents tend to add features that are not asked for.
Do I need a PRD for a side project?
A one-page version is worth it. Writing the problem, the non-goals and the core flow takes an hour and avoids days of rework, especially with an AI agent that will happily build anything you describe. For a weekend toy, the idea brief and a short build prompt may be enough.
Created with AI assistance and edited for this site. Examples are illustrative and do not represent customer research. About the publisher.