Write a Developer-Ready PRD

PRD stands for Product Requirements Document — a written spec that defines what a piece of software does, who it's for, and what "done" means. The minimum viable PRD has four sections: the problem, user stories with testable acceptance criteria, out-of-scope items with a one-line reason for each cut, and a phased delivery plan. This tool is a free AI PRD generator that produces all four in 5-10 minutes from a paragraph of product description, with the output sized for an MVP rather than an enterprise spec.

Start with the problem in two sentences — who hurts, when, and what the cost is today. Then write user stories in the format "As a [persona] I want [action] so that [benefit]" with 2-3 testable acceptance criteria each (the criteria are what make the story real — without them you have a wish, not a requirement). Tag generic features (auth, payments, file uploads) with a vendor instead of writing custom build specs. Add a one-page out-of-scope list naming what you cut and the simpler alternative. End with a phased plan against a fixed appetite, not a date. The agent above runs this exact pass and won't let a story close until the acceptance criteria exist.

Three rules. First, the format is non-negotiable: "As a [specific persona] I want [concrete action] so that [observable benefit]." Vague personas ("user") and vague benefits ("better experience") are how stories rot into wishes. Second, every story needs 2-3 acceptance criteria written as testable statements — "user receives a confirmation email within 30 seconds," "form rejects submission if any required field is empty." If you can't write the test, you can't write the story. Third, generic features (auth, payments, file uploads) get tagged with a vendor (Clerk, Stripe, Uploadcare) instead of an implementation spec — knowing how to write user stories also means knowing which ones not to write at all.

Yes — that's the primary use case. The PRD is plain Markdown with stable section headers (problem, user stories, acceptance criteria, out-of-scope, milestones) and the standard story format coding agents handle well. Drop it into Cursor's chat, attach it to a Claude Code project, or paste it into Lovable. The acceptance criteria become the test cases the AI codes against.

A BRD (Business Requirements Document) covers business needs and why. An MRD (Market Requirements Document) covers what the market wants. A PRD (Product Requirements Document) covers what the product does — features, user stories, acceptance criteria. Most early-stage founders only need a PRD. The BRD-flavoured content lives upstream in Lean Canvas.

If you're handing work to anyone — hire, agency, freelancer, or an AI coding tool — yes. The PRD is the contract that pins down what "done" means. Without it the developer guesses, the founder feels misled, and the build slips. With it, both sides have something to point at when a feature ships in a different shape than expected.

For an MVP, 2-5 pages. Anything longer and you're over-specifying. The job is to make scope explicit and acceptance testable, not to enumerate every UI state. I push back if the spec balloons past that range.

Appetite sizes instead of hourly estimates. S: 1-2 days, M: 3-5 days, L: 1-2 weeks, XL: 2+ weeks. Fixed time, flexible scope — you decide how much fits, not how long it takes. The full reasoning is in the Appetite, Not Estimates principle.

Real-time (+2-3 weeks), role-based permissions (L), file uploads with virus scanning and previews (M, not S), multi-tenancy (touches everything — decide now, not later). These are the features founders consistently underestimate. Each gets called out with effort impact and a simpler v1 — async messaging instead of real-time chat, admin/user instead of full RBAC.