PRD for Bolt: Structure your doc for seamless scaffolding
This page shows founders and PMs how to write a Product Requirements Document (PRD) for Bolt, the browser IDE that scaffolds apps from a single prompt. It targets Bolt's quirks: you must specify your tech stack (e.g., Next.js), database (e.g., Postgres), and deploy target (e.g., Vercel). Includes a real PRD example, actionable steps, and comparison of PRD doc styles.
What this is
A PRD for Bolt is a tailored Product Requirements Document designed to make Bolt—the full-stack browser IDE with one-prompt scaffolding—build your product correctly and quickly. Unlike generic PRDs, you need to specify your front-end framework (like Next.js, Astro, or Vite + React), your database (e.g., SQLite or Postgres), and deployment target (Vercel or Netlify) up front. This level of specificity ensures Bolt aligns its code output and deployment scripts to your chosen architecture. It’s a crucial handoff artifact between product and code, especially when leveraging AI tools like Bolt, Claude Code, or Replit: if you’re too vague, you’ll get the wrong app.
Compared to alternatives
| Option | Best for | Trade-off |
|---|---|---|
| Bolt PRD with explicit stack/deploy | AI-driven browser IDEs that automate setup from a spec (Bolt, Claude Code) | Takes more up-front detail; faster code delivery and fewer fixes later. |
| Traditional narrative PRD (Word doc, Confluence) | Human teams, early brainstorming, legacy handoffs | Easy to miss technical constraints; more back-and-forth when using AI tools like Bolt. |
| Feature-list PRD (Spreadsheets, Notion tables) | Tracking deliverables and priorities across teams | Lacks the architectural clarity Bolt needs for scaffolding and deployment. |
| UI-led PRD (Figma, v0 mocks) | Pixel-perfect product teams with design/eng split | UI visuals alone won’t direct Bolt to proper frameworks or infra choices. |
A real example
Product Requirements Document for Bolt: InstaPoll
1. Product Overview
Build a real-time, single-question polling app users can join via a shareable link. Intended for remote team standups. Track votes live. MVP scope: web only.
2. Stack
- Frontend/Backend: Next.js (App Router, TypeScript)
- Database: Postgres (Supabase hosted)
- Hosting/Deploy: Vercel
3. Key Features & Flows
- User can create a poll (max 1 question, 4 options). Poll auto-closes after 10 mins.
- Generated link for poll valid for 24 hours.
- Any visitor with the link can vote. No login.
- Votes update in real time (use Next.js API and Supabase real-time listeners).
- After voting, user sees poll results (option, percentage, count).
- Accessibility: meets WCAG 2.1 AA.
4. Success Metrics
- Set up time in Bolt: under 5 minutes from prompt to deploy
- MVP delivered by Bolt: 1 hour, usable end-to-end
- App supports 100 concurrent voters (tested via Supabase dashboard)
- <1s average poll load time on Vercel
5. Out-of-Scope
- No user accounts, authentication, multi-question polls, or mobile app.
6. Deploy Instructions (for Bolt prompt)
- Use Next.js and TypeScript
- Use Supabase Postgres for all DB needs
- Deploy to Vercel
- Scaffold code so src/pages/ and src/api/ match Next.js conventions
- Commit env vars for Postgres in .env.example
7. Open Questions
- Error states: show custom UI if poll invalid/expired?
- Should we log IP to guard against multiple votes per person? (defer)
8. Reference
- Similar: Typeform Fast Poll (but simpler)
- Tech inspiration: see TimeLogger app PRD: ship a freelance tracking MVP
How to use this
- Pick your stack up front: Decide between Next.js, Astro, SvelteKit, or Vite + React and name it in your PRD. Bolt needs this to scaffold the project directory and dependencies.
- Spell out the database choice: Declare SQLite, Postgres (e.g., Supabase), or 'none' for static apps. This impacts back-end code, data models, and config Bolt generates.
- Choose a deployment target: Specify Vercel or Netlify so Bolt can create compatible build and deploy scripts. If you don’t, you risk friction or failed deploys.
- Document features and flows tightly: Detail every primary workflow: user actions, data saved, real-time behavior. Bolt is literal—if it’s not listed, the AI may skip it.
- Define success and acceptance criteria: List speeds, supported users, accessibility, and what counts as a win. Bolt is fast, but tests what you measure, not what you imagine.
- Add out-of-scope and edge questions: Bolt won’t guess what you don’t say. Make limits and open questions explicit to keep code minimal and purposeful.
FAQ
What stack should I pick for Bolt?
Choose a stack Bolt natively supports and you’re comfortable with. Next.js is common for full-stack web apps, Astro is great for fast content sites, SvelteKit is lighter on boilerplate, and Vite + React is very customizable. Your stack guides directory and API structure—the more explicit you are, the less corrective work needed after Bolt scaffolds.
How do I specify the database for Bolt?
State Postgres (often via Supabase), SQLite, or "none". For cloud apps, Postgres is most robust, and Supabase integrates quickly. If your app doesn’t persist user data or is read-only, saying "no DB" skips backend code entirely. Ambiguity slows Bolt down—always specify.
Is it necessary to include deploy target in my PRD?
Yes. Bolt sets up build scripts and hosting specifically for Vercel or Netlify, so declaring your intended deploy target in the PRD means you avoid mismatch issues or rework later. It’s a one-line addition that saves an hour of debugging.
What makes a PRD for Bolt different from a standard PRD?
A Bolt PRD requires front-loaded technical specificity: stack, database, and deployment. Unlike a PRD meant for human dev teams, Bolt’s setup is literal—it won’t fill the gaps or make architectural guesses. The more explicit the spec, the less iteration and fix-up later.
Where can I find more PRD examples for Bolt projects?
Browse the Example PRDs page (/examples) and the PRD template hub (/templates). For ideas close to your project, see the SaaS PRD or internal tool PRD, as well as real-world filled docs like the TimeLogger app PRD.