A one-page product requirements document with ten sections: problem, buyer, MVP scope, non-goals, flow, data model, stack, success metric, open questions and notes for the agent. Copy it as Markdown, no signup.
Blank PRD template
# PRD: [Project name] > One sentence: what it does and who it is for. ## 1. Problem - **Who has it:** [a specific group, e.g. "Claude Code Max subscribers"] - **Evidence:** [links to threads, reviews or searches, with counts and dates] - **What they do today:** [the workaround, and why it hurts] ## 2. Who pays - **Buyer:** [who pulls out the card] - **Price and model:** [e.g. $5/mo, one-time $29, free with paid team plan] - **Why now:** [what changed that makes this worth building this month] ## 3. MVP scope (ship in 2 weeks or less) - [ ] [Must-have 1] - [ ] [Must-have 2] - [ ] [Must-have 3] ## 4. Non-goals - [Things you will not build in v1, even if asked] ## 5. User flow 1. [First thing the user does] 2. [What they see] 3. [The moment it pays off] ## 6. Data model | Entity | Fields | Notes | | --- | --- | --- | | [Entity] | [field: type, ...] | [source, retention] | ## 7. Stack and services - **App:** [framework, runtime] - **Data:** [database, storage] - **Payments and auth:** [provider] - **Hosting and monthly cost:** [provider, $ per month] ## 8. Success metric - [One number and one date, e.g. "20 paying users by Nov 30"] ## 9. Open questions - [ ] [Question you need answered before or during the build] ## 10. Notes for the coding agent - Build only what is in section 3. Ask before adding anything from section 4. - [Commands: how to run, test and lint] - [Files or folders the agent must not touch]
Most sections take two to five lines. If one runs longer, the scope is probably too big for a first version.
Problem
Who has it, the evidence with counts, and what they do today.
Who pays
The buyer, the price and why this is worth building now.
MVP scope
Three to five must-haves you can ship in two weeks.
Non-goals
What v1 will not do. This is what keeps an AI agent from overbuilding.
User flow
Three to five steps from install to the moment it pays off.
Data model
Entities and fields, so the agent doesn't invent a schema.
Stack and services
Framework, data, payments, hosting and the monthly cost.
Success metric
One number and one date.
Open questions
What you still need to find out.
Notes for the coding agent
Commands, files to leave alone, and the rule to build only section 3.
Filled in for an idea from our Claude Code ideas, backed by Reddit threads with 2,600+ upvotes from developers hitting usage limits mid-task.
Example PRD
# PRD: Usage limit radar > A menu bar app that shows what's left of your Claude Code, Codex and Cursor limits before a task dies mid-run. ## 1. Problem - **Who has it:** developers on Claude Max, ChatGPT Pro and Cursor Ultra plans who run long agent tasks. - **Evidence:** - "Investigating usage limits hitting faster than expected", r/ClaudeAI, 1,087 upvotes and 1,187 comments, Mar 2026 - "Users hitting usage limits WAY faster than expected", r/ClaudeCode, 950 upvotes, Apr 2026 - "I found the culprit eating your usage limit!", r/codex, 601 upvotes, Aug 2026 - **What they do today:** check each tool's usage page by hand, or find out when a task stops halfway. ## 2. Who pays - **Buyer:** the developer, from their own pocket. - **Price and model:** $5/mo. Free tier shows one tool. - **Why now:** all three tools changed their limits in 2026, and the threads above are recent. ## 3. MVP scope (ship in 2 weeks or less) - [ ] Read the local session logs for Claude Code and Codex, and count tokens per usage window - [ ] Menu bar item showing the remaining budget per tool - [ ] Notification at 80% of a window ## 4. Non-goals - Team dashboards and history (paid tier, later) - Windows and Linux builds - Cursor support until its usage data is readable locally ## 5. User flow 1. Install the app and grant read access to the log folders. 2. The menu bar shows a percentage per tool. 3. At 80% a notification says how long until the window resets. ## 6. Data model | Entity | Fields | Notes | | --- | --- | --- | | Tool | name, log_path, window_hours | one row per agent | | Session | tool, started_at, tokens_in, tokens_out | parsed from local logs, kept 30 days | | Alert | tool, threshold, sent_at | one per window | ## 7. Stack and services - **App:** Tauri (or Swift for macOS only) - **Data:** local SQLite file, nothing sent to a server - **Payments and auth:** license key through a payment provider - **Hosting and monthly cost:** none for v1, $0 ## 8. Success metric - 50 installs and 10 paying users within 30 days of the first post in r/ClaudeCode. ## 9. Open questions - [ ] Does each tool's log format stay stable between releases? - [ ] Can usage windows be computed from logs alone, without the provider's API? ## 10. Notes for the coding agent - Build only what is in section 3. Ask before adding anything from section 4. - Run `bun test` before every commit. - Never send log contents off the machine.
Write the problem first and link where people describe it: Reddit threads, app reviews, support tickets. Add counts and dates so you can tell a real pain from one loud post.
Write who pays and how much before you scope anything. If you can't fill this in, you have a hobby project, which is fine, but scope it like one.
List only what the first user needs to get the result. Everything else goes under non-goals.
Non-goals are the most useful section when an AI agent does the building. Agents add features you didn't ask for; a written non-goal is something you can point to.
A small table of entities and fields saves hours of refactoring later, and gives the agent something concrete to build against.
One number with a date, such as 10 paying users in 30 days. It tells you when to stop polishing and start selling.
docs/PRD.md.AGENTS.md or your Cursor rules: “Read docs/PRD.md before planning. Build only section 3.”Picking a stack? aistack.sh, our directory of tested AI tool stacks, lists the tools and monthly cost for an indie SaaS.
A product requirements document (PRD) describes what a product should do and why: the problem, who it is for, what is in and out of scope, and how you will know it worked. It says what to build, not how to write the code.
One page. The template above has ten short sections, and most take two to five lines. A long PRD for a solo project usually means the scope is too big.
The PRD covers the problem, the user and the scope. A technical spec covers architecture, APIs and implementation. For a solo project the stack and data model sections of this template cover enough of the spec to start.
Save it in your repo as docs/PRD.md and point to it from CLAUDE.md, AGENTS.md or your Cursor rules, for example: "Read docs/PRD.md before planning. Build only section 3." Then ask the agent for a plan based on the MVP scope before it writes code.
Yes. Copy the Markdown and paste it into a Notion page, which converts it to headings, lists and a table. In Google Docs, turn on Tools > Preferences > Enable Markdown, then use Edit > Paste from Markdown.
Yes. Copy or download it with no signup. The email box on this page is optional and only sends new templates and resources.