A one-page PRD for vibe coding: scope v1 so your AI tool builds less

Why AI-built projects sprawl

Four threads, one pattern

• It breaks around week three. A builder in r/vibecoding asked how to stop projects breaking about three weeks in, after accepting feature after feature until they no longer understood their own codebase (May 2026).^[1]
• Three weeks, no definition. Another r/vibecoding poster lost three weeks on a first SaaS and traced the failure to never defining what they had asked the AI to build (April 2026).^[2]
• Features nobody asked for. A third described adding feature after feature to an app that was not yet published (August 2026).^[3]
• Nothing written down. An r/SideProject post from 6 October 2026 argued that vibe-coded apps collapse because nobody writes down what the product is, or what done means, before prompting.^[4]

The one-page PRD template, plus four prompts to use with it

Copy the first block into a file called PRD.md (or into your builder's knowledge field, see the table below), fill the brackets and delete the hints. Or paste it into the draft prompt and let your chat model interview you section by section. Sections 3 and 4 are the reason this template exists: they are the two an AI tool cannot fill from its own memory. For section 7, the full checklist is on before you launch. For section 9, what one AI call costs shows how to set the caps.

# PRD: [app name], v1
Updated [date]. Read this file before every task.

## 1. User
One sentence: who has the problem, described the way they describe themselves.
[ ]

## 2. The one job
When [trigger], [user] wants to [job], so they can [result].
v1 does this one job end to end. Nothing else ships in v1.

## 3. Evidence line
Mark every line SOURCED (with a link) or ASSUMPTION.
- SOURCED: [link] shows [what it shows]
- ASSUMPTION: [what you believe and have not checked]
What they use today instead: [tool, spreadsheet, person, or nothing]

## 4. Riskiest assumption and pass signal
If this is wrong, v1 is pointless: [ ]
How I will test it: [ ]
Pass signal, with a number and a date: [ ]
If it passes: [the next assumption from section 3 you will test]
If it fails: [stop, narrow the user, or change the job]

## 5. Non-goals for v1
Do not build these, even if a prompt asks. Stop and ask me first.
- [ ]
- [ ]
Later list (ideas parked here, not in the code):
- [ ]

## 6. Screens and flow
No more than [3 to 5] screens.
- [Screen]: [what the user does there]

## 7. Data and access rules
- Data stored: [tables and fields]. Personal data: [which, and why].
- Users read and write only their own rows. On Supabase: Row Level Security on for every table. Elsewhere: every query filters by the signed-in user on the server.
- Secret keys stay on the server. Never in client code or in NEXT_PUBLIC_ or VITE_ variables.
- Every read and write checks the signed-in user on the server.

## 8. Acceptance checks (v1 is done when all pass, tested by hand)
- [ ] A new user can [do the job] from sign-up to result without help.
- [ ] User A cannot see or change user B's data (test with two accounts).
- [ ] Logged-out requests to [private pages and API routes] get a redirect or a 401.
- [ ] [a check for the job itself]

## 9. Cost guardrails
- Model: [model] for [task]. Max input: [N] characters.
- AI calls only after sign-in. Cap: [N] calls per user per day.
- Provider hard spend limit: [amount] per month.
- Build budget for v1: [credits or amount]. If it runs out, stop and re-scope.

## Rules for the agent
- Build one acceptance check at a time, in the order of section 8.
- If a request is in section 5, or is not covered by sections 2, 6 and 8, stop and ask.
- Do not change section 7 rules without asking.
- After each task, list every file you changed.

Help me fill the PRD template below for my app. Ask me one question at a time, in section order, and wait for each answer.
Do not invent facts, numbers, links, quotes or competitor names. In section 3, mark a line SOURCED only when I give you a link; mark everything else ASSUMPTION.
If my answers describe more than one job, make me pick one for v1 and move the rest to the Later list in section 5.
When every section is filled, print the full PRD.md, then list the three lines you trust least and why.
Template: [paste PRD.md here]

Read PRD.md in full. Do not write or change any code yet.
1. List anything in the PRD that is unclear, contradictory or missing, as questions for me.
2. Flag every place where the build depends on a line that section 3 marks ASSUMPTION.
3. Propose a build order that follows the acceptance checks in section 8, one feature per step, smallest first.
4. List anything you would normally add that section 5 rules out, so I can confirm it stays out.
Wait for my answers before you build anything.

Next task: make acceptance check [number] in PRD.md pass: "[paste the check]".
Touch only the files this needs. Do not add anything listed in section 5.
When you are done, tell me how to test it by hand, and list any change you made outside this check.

I want to add: [new idea].
Check it against PRD.md and answer in this order:
1. Does it serve the one job in section 2? Yes or no, and why.
2. Is it listed in section 5?
3. What would it change in sections 6 to 9 (screens, data rules, checks, cost)?
4. Your recommendation: build it now, add it to the Later list, or drop it.
Do not write any code for it.

Where your tool reads the PRD

Each tool below loads standing instructions on its own, so you do not paste the PRD into every prompt. File names, limits and plan modes were checked on each vendor's own docs on 2026-10-13 and are as of October 2026.

Checked on vendor docs 2026-10-13. Vendors rename files and change limits often; re-check before relying on a limit.^{[11], [12], [13], [14], [15], [16], [17], [18], [20], [21], [22], [23], [24], [25], [26], [31], [32], [33], [34]}

A filled example (editorial)

PRD: RFP draft helper, v1, section by section in the template's order. Section 4 tests one of the three assumptions in section 3.

• 1. User. Principal or office manager at an architecture firm of 5 to 20 people that answers public-sector RFPs and qualification requests without a proposal coordinator.
• 2. The one job. When an RFP or qualification request arrives, they want a first draft of the qualifications sections from the firm's past project sheets and staff resumes, so their hours go to the project-specific narrative.
• 3. Evidence line. SOURCED: two builders posted RFP tools for architecture firms in r/Architects in 2026; one says existing RFP platforms are built for enterprise sales teams. SOURCED: Google US (October 2026) for "ai rfp response software for architects" shows general RFP vendors, list articles and those two posts, and no architecture-specific product. SOURCED: Google US (October 2026): 6 of the top 10 results for "ai proposal generator" have "free" in the title, so a generic version competes with free tools. ASSUMPTION: small firms pay for RFP help today (a consultant, a coordinator or partner hours). ASSUMPTION: firms keep past project sheets and resumes as files. What they use today instead: ASSUMPTION, Word templates and copy-paste.^{[27], [28], [29], [30]}
• 4. Riskiest assumption and pass signal. Riskiest (the second ASSUMPTION in section 3): firms keep past project sheets and resumes as files, and will upload them and edit a draft instead of starting from their own last response. Test: ask 10 firms for one recent RFP and their last response, and draft one response by hand. Pass: 3 of 10 send files within 14 days, and 1 asks to use a draft on a live bid. If it passes, test payment next: offer the firms that sent files a set price for drafts on their next 2 bids. If it fails: narrow to one section, such as staff resumes, or stop.
• 5. Non-goals for v1. Finding RFPs or bid alerts. Team accounts (one login per firm). Fee proposals and pricing. Integrations with accounting or project-management software. Page layout and design export beyond .docx. A mobile app. A chat assistant.
• 6. Screens and flow. Library: upload project sheets and resumes. New response: upload the RFP. Draft: sections matched to the RFP's requirements, each showing the file it came from, with a .docx export.
• 7. Data and access rules. Firm files private to the firm's account, in a private bucket. Users read and write only their firm's rows; on Supabase, Row Level Security on every table. Secret keys on the server. Files deleted on request. Read the model provider's data terms before the first real upload.
• 8. Acceptance checks. A new firm uploads 5 project sheets and gets a draft for a sample RFP without help. Every draft paragraph names the file it came from. Firm A cannot open firm B's files (two-account test). Logged-out requests to the library and the API get a redirect or a 401.
• 9. Cost guardrails. One batch of model calls per draft. At most 10 drafts per firm per day, 20 MB per file. AI calls only after sign-in. Provider hard spend limit set before the first outside user. A written build budget for v1; if it runs out, stop and re-scope.

The same example as one PRD.md, ready to copy and compare against your own.

# PRD: RFP draft helper, v1
Updated 2026-10-13. Read this file before every task.

## 1. User
Principal or office manager at an architecture firm of 5 to 20 people that answers public-sector RFPs and qualification requests without a proposal coordinator.

## 2. The one job
When an RFP or qualification request arrives, they want a first draft of the qualifications sections from the firm's past project sheets and staff resumes, so their hours go to the project-specific narrative.
v1 does this one job end to end. Nothing else ships in v1.

## 3. Evidence line
- SOURCED: two builders posted RFP tools for architecture firms in r/Architects in 2026; one says existing RFP platforms are built for enterprise sales teams. https://www.reddit.com/r/Architects/comments/1sbwryz/ https://www.reddit.com/r/Architects/comments/1rk34wx/
- SOURCED: Google US (October 2026) for "ai rfp response software for architects" shows general RFP vendors, list articles and those two posts, and no architecture-specific product. https://www.google.com/search?q=ai+rfp+response+software+for+architects
- SOURCED: Google US (October 2026): 6 of the top 10 results for "ai proposal generator" have "free" in the title, so a generic version competes with free tools. https://www.google.com/search?q=ai+proposal+generator
- ASSUMPTION: small firms pay for RFP help today (a consultant, a coordinator or partner hours).
- ASSUMPTION: firms keep past project sheets and resumes as files.
What they use today instead: ASSUMPTION, Word templates and copy-paste.

## 4. Riskiest assumption and pass signal
If this is wrong, v1 is pointless: the second ASSUMPTION in section 3. Firms keep past project sheets and resumes as files, and will upload them and edit a draft instead of starting from their own last response.
How I will test it: ask 10 firms for one recent RFP and their last response, and draft one response by hand.
Pass signal: 3 of 10 send files within 14 days, and 1 asks to use a draft on a live bid.
If it passes: test payment next. Offer the firms that sent files a set price for drafts on their next 2 bids.
If it fails: narrow to one section, such as staff resumes, or stop.

## 5. Non-goals for v1
- Finding RFPs or bid alerts
- Team accounts (one login per firm)
- Fee proposals and pricing
- Integrations with accounting or project-management software
- Page layout and design export beyond .docx
- A mobile app
- A chat assistant
Later list:
- (empty)

## 6. Screens and flow
- Library: upload project sheets and resumes
- New response: upload the RFP
- Draft: sections matched to the RFP's requirements, each showing the file it came from, with a .docx export

## 7. Data and access rules
- Firm files private to the firm's account, in a private bucket.
- Users read and write only their firm's rows. On Supabase: Row Level Security on every table.
- Secret keys on the server.
- Files deleted on request. Read the model provider's data terms before the first real upload.

## 8. Acceptance checks
- [ ] A new firm uploads 5 project sheets and gets a draft for a sample RFP without help.
- [ ] Every draft paragraph names the file it came from.
- [ ] Firm A cannot open firm B's files (two-account test).
- [ ] Logged-out requests to the library and the API get a redirect or a 401.

## 9. Cost guardrails
- One batch of model calls per draft. At most 10 drafts per firm per day, 20 MB per file.
- AI calls only after sign-in.
- Provider hard spend limit set before the first outside user.
- A written build budget for v1; if it runs out, stop and re-scope.

## Rules for the agent
- Build one acceptance check at a time, in the order of section 8.
- If a request is in section 5, or is not covered by sections 2, 6 and 8, stop and ask.
- Do not change section 7 rules without asking.
- After each task, list every file you changed.

What v1 leaves out

Our default cut list for a solo builder's first version (editorial). Tick each item you are leaving out and copy it into section 5. If one of these is the job itself, keep it and cut something else. For ways to do parts by hand first, see How to scope an MVP.

• Team accounts, roles and invites. One user type in v1. Add seats when a paying customer asks for a second login.
• An admin panel. Use your database's own table editor to look at and fix data.
• A native mobile app. Ship a web app that works on a phone. Store builds add review rules and fees; read app store fees and review rules before you add one.
• More than one sign-in method. One method, such as an emailed code or one social login. Each extra provider is another setup to secure and test.
• Billing tiers and plan logic. If "will they pay" is your riskiest assumption, test it with one price and a hosted checkout from your payment processor. Otherwise leave payments out of v1. Fees by processor are in what it costs to run.
• Polish: settings, themes, tours. Pick defaults and onboard your first users yourself, on a call or by email.
• Notifications and email beyond sign-in. Send the few messages v1 needs by hand, or from one template.
• Integrations (Slack, calendar, Zapier, CRM). Offer a CSV export or a copy button first. Build the integration the first customer asks for by name.
• AI features that are not the one job. A chat assistant on every screen adds model cost per user and more input to secure.

Keep the agent inside the PRD

1. 1
   Plan before anything bigger than a tweak. Claude Code and Codex (Shift+Tab or /plan), Cursor (Shift+Tab), Lovable (Plan in the mode picker), Bolt (Plan in the chatbox), Replit (the Plan toggle), Devin Desktop (the mode selector) and GitHub Copilot (the agents dropdown) each have a mode that plans before it edits code. Paste the kickoff prompt there first. Planning is not free everywhere: as of October 2026 a Lovable Plan message costs 1 credit plus any subagent research, and Replit bills Plan mode like other Agent work.^{[12], [14], [16], [18], [21], [31], [32], [33]}
2. 2
   One feature per prompt, in the order of section 8. Bolt's getting-started guide says: "Do one thing at a time." One acceptance check per prompt also keeps each change small enough to read.^[19]
3. 3
   Send new ideas to the Later list. When you or the agent think of a feature, run the scope-check prompt and park the idea in the Later list at the bottom of section 5. The codebase only gets what the PRD has (editorial).
4. 4
   Read the diff against the PRD. Look at what changed before you accept it. If files outside the task changed, ask why before moving on. For something that must never happen, an instruction is not enough: Claude Code's docs point to a PreToolUse hook to block an action whatever the model decides.^[11]
5. 5
   Keep it short, and reload it after edits. Claude Code says longer CLAUDE.md files reduce adherence, Cursor advises splitting rules over 500 lines, and Codex stops adding instruction files at its 32 KiB default. Codex also reads its instructions once per run, so restart it after you edit AGENTS.md. If the PRD outgrows a page, move feature detail into a second file and keep the PRD as the index.^{[11], [13], [24]}

Common questions

Sources

Each number in brackets on this page points here. Prices and limits change; the date is when we read the page.

1. [1]r/vibecoding: how to stop the project from breaking after three weeks into the build (2026-05-27) · accessed 13 October 2026
2. [2]r/vibecoding: I wasted 3 weeks trying to build my first SaaS with AI (2026-04-28) · accessed 13 October 2026
3. [3]r/vibecoding: I'm going into a multi feature syndrome (2026-08-08) · accessed 13 October 2026
4. [4]r/SideProject: The thing nobody writes down before prompting is why vibe-coded apps collapse (2026-10-06) · accessed 13 October 2026
5. [5]Supabase docs: Row Level Security · accessed 13 October 2026
6. [6]Next.js docs: Environment variables · accessed 13 October 2026
7. [7]Vite docs: Env variables and modes · accessed 13 October 2026
8. [8]OWASP GenAI Security Project: LLM10:2025 Unbounded Consumption · accessed 13 October 2026
9. [9]OpenAI API docs: Spend limits · accessed 13 October 2026
10. [10]Claude Platform docs: Rate limits (spend limits section) · accessed 13 October 2026
11. [11]Claude Code docs: How Claude remembers your project (CLAUDE.md and AGENTS.md) · accessed 13 October 2026
12. [12]Claude Code docs: Choose a permission mode (plan mode) · accessed 13 October 2026
13. [13]Cursor docs: Rules · accessed 13 October 2026
14. [14]Cursor docs: Plan Mode · accessed 13 October 2026
15. [15]Lovable docs: Define workspace and project knowledge · accessed 13 October 2026
16. [16]Lovable docs: Plan a change in Plan mode · accessed 13 October 2026
17. [17]Bolt support: Project settings (Knowledge) · accessed 13 October 2026
18. [18]Bolt support: Plan before building with Plan Mode · accessed 13 October 2026
19. [19]Bolt support: Project lifecycle (build your first app) · accessed 13 October 2026
20. [20]Replit docs: replit.md · accessed 13 October 2026
21. [21]Replit docs: Plan Mode · accessed 13 October 2026
22. [22]Replit docs: Agent Customization (custom instructions and skills) · accessed 13 October 2026
23. [23]v0 docs: Instructions · accessed 13 October 2026
24. [24]OpenAI Codex docs: Custom instructions with AGENTS.md · accessed 13 October 2026
25. [25]Devin Desktop docs: Memories and rules · accessed 13 October 2026
26. [26]GitHub Docs: Adding repository custom instructions for GitHub Copilot · accessed 13 October 2026
27. [27]r/Architects: Built an AI-powered RFP tool specifically for architecture firms (builder post, 2026) · accessed 13 October 2026
28. [28]r/Architects: I built a tool to speed up RFP responses (builder post, 2026) · accessed 13 October 2026
29. [29]Google US top 10 for "ai rfp response software for architects" (checked through Serper) · accessed 13 October 2026
30. [30]Google US top 10 for "ai proposal generator" (checked through Serper) · accessed 13 October 2026
31. [31]OpenAI Codex docs: Best practices (Plan mode) · accessed 13 October 2026
32. [32]Devin Desktop docs: Cascade modes (Plan mode) · accessed 13 October 2026
33. [33]GitHub Docs: Using plan mode in your IDE · accessed 13 October 2026
34. [34]Devin Desktop docs: FAQ (Devin Desktop is the new name for Windsurf) · accessed 13 October 2026

Read next

• Stage 2: check demandValidate your app idea before you build it
• Stage 2: check demandPrompts to validate a business or app idea
• Stage 4: ship and find usersBefore you launch a vibe-coded app: data, keys, backups
• Stage 3: build itLovable vs Bolt vs Replit vs v0 vs Base44