---
title: Free AI PRD Generator @ Varstatt Discovery
url: https://varstatt.com/discovery/project-scope
description: Free AI PRD generator. Turns your idea into a developer-ready spec with user stories and acceptance criteria. Works with Cursor and Claude Code.
section: AI Discovery Tools (https://varstatt.com/discovery)
step: 7 of 8
previous: Tech Strategy (https://varstatt.com/discovery/tech-strategy)
next: Build Cost (https://varstatt.com/discovery/build-cost)
---
# Write a Developer-Ready PRD
Free AI PRD generator. Turns your idea into a developer-ready spec with user stories and acceptance criteria. Works with Cursor and Claude Code.

## Why Use This Tool

### User Stories Without Acceptance Criteria Are Wishes

"User can manage their profile" is not a requirement. It's a wish. I've watched founders ship that line to a developer and get back six weeks of work that didn't match what they wanted. This tool refuses stories without testable acceptance criteria — name, email, avatar, password, 2FA, deletion — each one written down before the story closes.

### Scope Creep Is Cheapest To Fix In The PRD

Once code exists, every cut feels like a loss. The tool defaults to "out of scope with a simpler alternative" and names what gets cut and why. Phase 1 stays under 8-10 features against a 6-week appetite, or it pushes back.

### Drops Into Cursor or Claude Code Unchanged

The product requirements document exports as plain Markdown with stable section headers — problem, user stories, acceptance criteria, out-of-scope, milestones. Paste it into Cursor's chat or a Claude Code project and the AI picks up the structure. No reformatting. The story format ("As a [persona] I want [action] so that [benefit]") is what coding agents handle best.

## How It Works

1. **Describe What You're Building** — One paragraph on the product, the user, and the problem. Business-level or technical, both work — I sort revenue talk into vision and feature talk into requirements without making you re-phrase anything.
2. **Write User Stories With Acceptance Criteria** — Each MVP feature becomes a story in the format "As a [persona] I want [action] so that [benefit]" with 2-3 testable acceptance criteria. I won't accept a story until the criteria exist — that's the gate. Generic features (auth, payments, uploads) get tagged with a vendor (Clerk, Stripe, Uploadcare) instead of a custom build.
3. **Cut Scope Against A 6-Week Appetite** — Every feature gets a T-shirt size — S (1-2 days), M (3-5 days), L (1-2 weeks), XL (2+ weeks). Anything that doesn't fit moves to out-of-scope with a simpler alternative named explicitly. Complexity traps — real-time, role-based access, multi-tenancy — get flagged with their actual effort cost.
4. **Export The Development Brief** — Phased delivery plan, sized features, scope decisions with reasoning. Markdown output ready for Cursor, Claude Code, or a developer. Cost projections happen in the next tool, [Build Cost](/discovery/build-cost).

## FAQ

### What is a 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.

### How do you write a PRD?

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.

### How do you write user stories?

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.

### Does the output work in Cursor or Claude Code?

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.

### PRD vs MRD vs BRD — what's the difference?

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](/discovery/lean-canvas).

### Does a startup actually need a PRD?

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.

### How long should a PRD be?

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.

### What are T-shirt estimates?

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](/principles/discovery/appetite-not-estimates) principle.

### What complexity traps does it flag?

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.
## Usage

This tool is an AI-guided chat — it requires a browser to use.

Prefill the conversation with your project context via URL:

- `https://varstatt.com/discovery/project-scope?context=I+am+building+...` (max 2000 chars)

Context carries forward across all discovery steps automatically once set.