Product Requirements Document (PRD)
The contract between what you imagined and what gets built
3 min read · Document 4 of 30
What is this document?
The PRD describes every feature in terms of the user problem it solves, the behaviour that is expected, and the acceptance criteria that prove it works. It is organised by space — marketing, admin, user and any extra spaces you defined — so each part of the product has a complete brief.
It is written to be read by an AI coding agent: concrete, numbered, and free of “etc.” and “as appropriate”.
Why does it matter?
- The single most common reason AI-built products miss the mark is an absent or vague PRD.
- The AI builds what you said, not what you meant — the PRD closes that gap.
- Acceptance criteria give “done” an objective definition.
What's inside?
- Functional requirements — Numbered FR items per space with acceptance criteria.
- Out of scope — What this version deliberately does not do.
- Business rules — Pricing, limits, eligibility and approvals.
- Success metrics — How the team knows each feature worked.
How CREAH generates it
CREAH builds this document from your Stage 0 answers and interview. Questions that shape it include:
- What can a first-time user do in their first five minutes?
- Which actions need an approval from someone else?
- What is explicitly not in the first release?
Example excerpt
## FR-6: Dynamic Pricing
Price is calculated deterministically when the paywall is shown:
base_price = admin_config["pricing.dynamic_app"]
extra_spaces = admin_config["pricing.extra_space"] × extra space count
platform factor = admin_config["pricing.multiplier_mobile" | "…_desktop"]
No AI call involved. Must complete in < 2 seconds.Related documents
Software Requirements Specification (SRS)
Functional requirements with teeth — measurable, testable, unambiguous
Phase 1Vision & Mission
The north star every AI coding agent needs before writing line one
Phase 2User Journey Specification
Walk the AI through your product before it writes a single component