6 PRD Best Practices
Before filling in the template, understand what makes a PRD useful versus one that collects dust.
Document Header & Overview
Every PRD starts with metadata that tells anyone who reads it exactly what they are looking at, when it was written, who owns it, and what stage it is at.
Document Metadata
Executive Summary
Hint: 2–4 sentences. Summarise what the product is, who it is for, and what this PRD covers. Write this last — after all other sections are complete.
e.g. ProposalAI is a web application that enables freelance designers to generate professional client proposals in under 10 minutes using AI. The product addresses the 3–5 hours per week that freelancers currently spend manually creating proposals in Google Docs or generic tools. This PRD covers the MVP feature set targeting solo freelance designers, defining requirements for the proposal generation engine, client viewer, and Stripe payment integration.
Background & Problem Statement
The background section provides context for why this product or feature is being built. It aligns everyone on the problem before discussing solutions.
Problem Statement
Hint: Describe the problem concisely. Include who experiences it, how frequently, and what the measurable impact is.
e.g. Freelance designers spend 3–5 hours per week creating client proposals manually. This process involves copying from old proposals, reformatting in Google Docs, manually calculating pricing, and writing custom descriptions for each project type. The result is inconsistent quality, lost time that could be spent on paid work, and slow turnaround that loses deals to faster competitors.
Background & Context
Hint: Cite research, data, or interviews that validate the problem. Numbers make this section credible.
e.g. User research conducted August 2025 with 24 freelance designers revealed: • Average time spent on proposals: 3.2 hours/week • 68% lose deals because proposals take too long to send • 71% have sent proposals with pricing errors • Existing tools (Bonsai, HoneyBook) are generic and not designer-specific • 82% would pay for a tool that reduced this time to under 30 minutes
Current Solutions & Gaps
Hint: Map the competitive landscape. Be specific about where existing solutions fall short.
e.g. Current market solutions and their limitations: • Google Docs — Free but entirely manual, no automation, inconsistent formatting • Bonsai ($19/mo) — Generic service templates, not designer-specific, no AI • HoneyBook ($16/mo) — Built for coaches and consultants, poor UX for designers • PandaDoc ($49/mo) — Enterprise-focused, too expensive and complex for solo freelancers The gap: no tool combines AI generation + designer-specific templates + embedded Stripe payments at an accessible price point.
Opportunity Statement
Hint: The opportunity is the flip side of the problem. Frame it as the market gap you are addressing.
e.g. An AI-powered proposal tool built specifically for freelance designers — with design project templates, automatic pricing calculation, and embedded Stripe payment links — could reduce proposal creation from 3 hours to under 10 minutes and capture a meaningful share of the 2M+ freelance designer market in English-speaking countries.
Goals & Success Metrics
Define what success looks like before development begins. Goals align the team. Metrics make success measurable and unambiguous.
Business Goals
Hint: Business goals should be specific, time-bound, and measurable. Avoid vague goals like 'grow the user base'.
e.g. • Reach $10,000 MRR within 6 months of launch • Acquire 500 registered users within 90 days • Achieve trial-to-paid conversion rate above 25% • Maintain monthly churn below 5% • Generate 50 qualified inbound leads per month via organic search
Product Goals
Hint: Product goals focus on user behaviour and experience, not revenue. What does good product health look like?
e.g. • 80% of users complete a proposal within 10 minutes of first login • Achieve NPS score above 50 within 60 days of launch • Reduce support tickets related to proposal generation to under 5% of active users • 70% of users who send a proposal return to send a second within 30 days
North Star Metric
Hint: One metric that best represents value delivered to users. Everything in the product should serve this metric.
e.g. Proposals sent per week — because every sent proposal represents a user who has experienced the core value of the product. All product decisions should increase this number.
Key Performance Indicators (KPIs)
Out of Scope for This Release
Hint: Being explicit about what you are NOT measuring prevents confusion during reviews.
e.g. The following will NOT be measured or targeted in this release: • Mobile app metrics (iOS/Android not in MVP) • Enterprise team metrics (multi-seat plans not in MVP) • API usage metrics (developer API not in MVP) • Marketplace metrics (template marketplace deferred to v2)
Target Users & Personas
Define exactly who this product is built for. Every requirement, user story, and design decision should be evaluated against these personas.
Primary Persona
Alex — Freelance UX Designer
Demographics
Goals
Pain Points
Secondary Persona
Hint: Only define a secondary persona if they meaningfully influence MVP scope. Otherwise, note them and defer.
e.g. Jordan — Design Studio Owner Age: 32–45, runs a studio of 2–5 designers. Needs to standardise the proposal process across their team. Currently, each designer sends proposals in different formats with inconsistent pricing. Goals: consistency across team, faster proposal turnaround, professional brand presentation. Pains: no way to enforce a standard format, difficult to track proposal status across team members. Note: Secondary persona needs are deferred to v2 (team/multi-seat features). MVP is built exclusively for the primary persona.
User Journey (Primary Persona)
Discovers ProposalAI
Via Product Hunt, Dribbble, or search. Lands on marketing site.
Signs Up
Email signup or Google OAuth. No credit card required for trial.
Onboarding
Sets up profile — name, brand colours, logo. Selects primary project types.
Creates First Brief
Fills in project brief form — client name, project type, scope, timeline, budget.
AI Generates Proposal
Claude generates proposal content. User reviews and edits inline.
Sends to Client
Shares unique proposal link. Client views in browser.
Client Accepts
Client accepts proposal. Stripe payment link allows immediate deposit payment.
Returns for Next Project
User creates second proposal. Habit formed. Converts to paid plan.
User Stories
User stories capture requirements from the user's perspective. Each story follows the format: As a [user], I want to [action], so that [benefit]. Each has clear acceptance criteria.
Authentication & Onboarding
Proposal Creation
Proposal Delivery
Dashboard & Management
Functional Requirements
Functional requirements define what the system must do. Unlike user stories, they are written from the system's perspective and are directly testable.
Authentication System
Proposal Generation Engine
Billing & Subscriptions
Proposal Delivery & Client View
Non-Functional Requirements
Non-functional requirements define how the system performs — quality attributes like speed, security, reliability, and scalability that users experience but rarely articulate.
Performance Requirements
Security Requirements
Hint: Security requirements are non-negotiable. Every item here should be verified before launch.
NFR-SEC-001: All data in transit encrypted via TLS 1.2 or higher NFR-SEC-002: All passwords hashed with bcrypt (cost factor ≥ 12) — never stored in plain text NFR-SEC-003: All database queries use parameterised statements — no raw SQL string interpolation NFR-SEC-004: Row-level security enabled on all Supabase tables — users can only access their own data NFR-SEC-005: File uploads validated for type (allowlist), size (max 5MB), and scanned before storage NFR-SEC-006: Admin panel accessible only to users with admin role — enforced at database and API level NFR-SEC-007: API keys and secrets stored in environment variables — never committed to version control NFR-SEC-008: Security headers configured: CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
Availability & Reliability
Hint: Define availability expectations explicitly. This sets the standard your infrastructure must meet.
NFR-REL-001: System must achieve 99.5% uptime measured monthly (max 3.6 hours downtime/month) NFR-REL-002: Database must be backed up automatically every 24 hours with 30-day retention NFR-REL-003: System must have error monitoring in place (Sentry) that alerts on error rate > 1% NFR-REL-004: System must have uptime monitoring (Uptime Robot) that alerts within 2 minutes of downtime NFR-REL-005: All Stripe webhooks must be processed with retry logic — minimum 3 retry attempts on failure NFR-REL-006: System must degrade gracefully if Anthropic API is unavailable — queuing or informative error shown
Scalability Requirements
Hint: Scalability requirements ensure you do not need expensive rewrites as you grow.
NFR-SCALE-001: System must handle 500 concurrent users without performance degradation at MVP launch NFR-SCALE-002: Database schema must be designed to support 100,000 proposals without structural changes NFR-SCALE-003: AI generation must support 50 concurrent requests without timeouts (managed via queue if needed) NFR-SCALE-004: File storage architecture must support 1TB of proposal assets without architectural changes NFR-SCALE-005: Authentication system must handle 10,000 registered users on free Supabase Auth tier
Accessibility Requirements
Hint: Accessibility is both a legal requirement in many markets and good product practice.
NFR-A11Y-001: All pages must meet WCAG 2.1 Level AA compliance NFR-A11Y-002: All interactive elements must be keyboard navigable NFR-A11Y-003: All images must have descriptive alt text NFR-A11Y-004: Colour contrast ratio must be minimum 4.5:1 for normal text NFR-A11Y-005: Forms must have properly associated labels and clear error messages NFR-A11Y-006: Proposal viewer must be readable without JavaScript (SSR)
Technical Specifications
Technical specifications give the engineering team clarity on architectural decisions, integration requirements, and constraints before they begin implementation.
System Architecture
Hint: Describe the high-level architecture in plain language. Diagrams can be linked or attached separately.
e.g. ProposalAI uses a JAMstack architecture: • Frontend: Next.js 14 (App Router) deployed on Vercel • Backend: Supabase (PostgreSQL + Auth + Storage + Edge Functions) • AI Layer: Anthropic Claude API (claude-sonnet-4-6) called from Next.js API routes • Payments: Stripe Billing (subscriptions) + Stripe Checkout (client deposit payments) • Email: Resend + React Email templates • Error Tracking: Sentry • Analytics: Posthog • CDN: Vercel Edge Network All communication between frontend and Supabase uses the Supabase JS client. AI generation requests are proxied through a Next.js API route to protect the Anthropic API key.
Database Schema (Key Tables)
Hint: Define the key tables and their relationships. You do not need to be exhaustive — focus on the most important entities.
Key tables in the PostgreSQL database:
users (extends Supabase auth.users)
- id: uuid (FK to auth.users)
- display_name: text
- logo_url: text
- brand_primary: text (hex)
- brand_secondary: text (hex)
- plan_tier: enum ('free', 'pro')
- stripe_customer_id: text
- created_at: timestamptz
proposals
- id: uuid (PK)
- user_id: uuid (FK to users)
- client_name: text
- project_type: text
- status: enum ('draft', 'sent', 'viewed', 'accepted', 'declined')
- content: jsonb (structured proposal sections)
- total_value: numeric
- public_token: uuid (used in public URL)
- created_at: timestamptz
- updated_at: timestamptz
RLS policy: users can only SELECT/INSERT/UPDATE/DELETE their own proposals (user_id = auth.uid())API Endpoints
Third-Party Integrations
Hint: For each integration, define the purpose, authentication method, and which events or endpoints are used.
Anthropic Claude API - Model: claude-sonnet-4-6 - Use: Proposal generation from project brief - Auth: ANTHROPIC_API_KEY (env variable, server-side only) - Rate limits: 60 requests/minute on Tier 1 — sufficient for MVP - Streaming: Yes — SSE via API route proxy Stripe - Products: Stripe Billing (subscriptions), Stripe Checkout (client deposits) - Webhook events handled: invoice.paid, invoice.payment_failed, customer.subscription.updated, customer.subscription.deleted - Keys: STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET (env variables) Resend - Use: Transactional email (welcome, verification, proposal viewed, payment confirmation) - From address: hello@proposalai.co - Templates: React Email components Posthog - Use: Product analytics (events, funnels, session recordings) - Key events: signup, proposal_created, proposal_generated, proposal_sent, proposal_viewed, proposal_accepted, upgrade_started, upgrade_completed
Design & UX Requirements
Design requirements align engineering and design on visual standards, interaction patterns, and UX principles before implementation begins.
Design System
Hint: Define the design system tokens that engineers should use. Link to Figma if available.
e.g. ProposalAI uses a custom design system built on top of Tailwind CSS and shadcn/ui components: • Typography: Inter (Google Fonts) — headings at 700 weight, body at 400 • Primary brand colour: #0070F3 (blue) • Secondary: #F4F4F5 (light grey for backgrounds) • Success: #22C55E · Error: #EF4444 · Warning: #F59E0B • Border radius: 8px (small), 12px (medium), 16px (large) • Spacing scale: 4px base unit (4, 8, 12, 16, 24, 32, 48, 64, 80px) Design files: Figma link — [insert Figma link here] Component library: /components/ui in the codebase
Key UX Requirements
Hint: UX requirements define the experience standards engineers and designers must meet. Be specific.
UX-001: The brief-to-proposal flow must not require more than 3 screens — brief form → generation → editor UX-002: All form inputs must show inline validation errors (not on submit only) UX-003: Destructive actions (delete proposal, cancel subscription) must require a confirmation step UX-004: All async operations must show loading state — no silent operations UX-005: Empty states must be designed for all list views — first proposal creation should be obvious UX-006: Onboarding flow must have a visible progress indicator UX-007: The proposal editor must auto-save — no explicit save button required UX-008: Mobile layout must be fully functional — not just 'responsive but broken' UX-009: All error messages must explain what went wrong AND what the user should do next UX-010: Navigation must make the user's current location in the app clear at all times
Responsive Breakpoints
Hint: Define the breakpoints and which layouts apply at each. Be specific about mobile requirements.
Mobile: 375px–767px — single column layout, full-width forms, bottom sheet modals Tablet: 768px–1023px — two-column layout where appropriate, side navigation collapsed Desktop: 1024px+ — full navigation sidebar visible, multi-column dashboard layout Critical: The client-facing proposal view must be pixel-perfect on mobile — this is a conversion surface.
Release Criteria & Open Questions
Release criteria define the conditions that must be met before this product ships. Open questions document unresolved decisions that need answers before or during development.
Launch Blockers (must be true before shipping)
Hint: These are binary conditions. Change ✗ to ✓ as each is verified. Nothing ships until all are ✓.
LAUNCH-001 ✗ All Must Have user stories pass acceptance criteria LAUNCH-002 ✗ All Critical functional requirements implemented and tested LAUNCH-003 ✗ All Critical non-functional requirements met (security, performance) LAUNCH-004 ✗ Privacy Policy and Terms of Service published and linked LAUNCH-005 ✗ Stripe billing fully functional in production (not test mode) LAUNCH-006 ✗ Error monitoring (Sentry) live and alerting correctly LAUNCH-007 ✗ Analytics (Posthog) tracking all key events in production LAUNCH-008 ✗ Database backups configured and tested (verified restore) LAUNCH-009 ✗ Email delivery tested end-to-end in production environment LAUNCH-010 ✗ Load test passed — system handles 100 concurrent users without errors
Definition of Done (per feature)
Hint: A shared definition of done prevents 'done' meaning different things to different team members.
A feature is considered complete and shippable when ALL of the following are true: □ All acceptance criteria from user stories pass □ Unit tests written and passing for business logic □ Manual QA completed on Chrome, Safari (iOS and macOS), and Chrome for Android □ Responsive layout verified at 375px, 768px, and 1280px □ No console errors or warnings in production build □ Sentry error tracking verified for any new error surfaces □ Posthog events firing for all relevant user actions □ Code reviewed and approved by at least one other team member □ Deployed to staging and verified before promotion to production
Open Questions
Should free tier users be able to share their proposal publicly, or should we require a paid plan to unlock the client view?
What happens to proposals when a user's subscription lapses — are they viewable? Editable? Or locked?
Should we allow clients to leave comments on the proposal before accepting, or is accept/decline binary for MVP?
Do we need to handle VAT / GST on the Stripe subscription for EU and Australian customers at launch?
What is our policy on AI-generated content ownership — who owns the proposal text, us or the user?
Should we log the AI prompts and responses for quality improvement, and does this require disclosure in the privacy policy?
Revision History
Hint: Track every meaningful change with a date, version, and author. This prevents confusion about which version is current.
v1.0 — 15 September 2025 — Initial draft (Sarah Chen) v1.1 — 22 September 2025 — Added non-functional requirements, updated user stories US-007 and US-008 after design review v1.2 — 1 October 2025 — Added API endpoint table, updated database schema after engineering review. Moved Google OAuth from Must Have to Should Have per kickoff scope discussion. v1.3 — 10 October 2025 — Added open questions section. Resolved Q-004 (VAT deferred). Updated success metrics based on revised MRR target.
Got your PRD? We build it.
This template is the exact document structure we use with clients before every build. A completed PRD handed to our team means faster, more accurate development with fewer revision rounds.
If you have completed this PRD and are ready to build, we can take your requirements document and ship your product in 28 days — no guesswork, no scope creep, no surprise costs.
Products Shipped
From PRD to production
MVP Delivery
Fixed-price, full-stack
Surprise Costs
Scope defined upfront
Response Time
On all new enquiries