Phase 2 — Requirements

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.
From a one-line prompt to verifiable requirements

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.

Ready to generate your Product Requirements Document (PRD)?