PRD (product requirements document)
Written before the build starts, it sets out what the product must do, for whom and under which rules, so both sides can check the work against it.
Updated October 2026 · with examples from our own builds
What does PRD mean in practice?
A PRD turns a conversation into something checkable. A useful one names every role, what each person needs to get done, the data the system keeps, the rules it enforces and what counts as finished. It can be one document or forty; what matters is whether a developer could build from it without guessing.
Paper is the cheapest place to change your mind. Moving a screen in a document costs minutes; moving it after the database and the API have been built around it costs days, and the change request that follows is where budgets start to drift.
The usual gap is a PRD that lists features but not rules. It says 'invoices' without saying who issues them, how they are numbered or what happens when one is voided, and those blanks get filled during the build by whoever happens to be writing the code.
PRD at a glance
- Who writes it
- The product lead or agency, reviewed line by line by the founder
- Best test
- Whether a developer could estimate from it without a call
- Lives on as
- The reference for acceptance tests and change requests
Where has PRD come up in our builds?
We wrote the product plan first: 44 documents covering every role, how the roles connect, the case engine, money and countries. The platform was then built in slices against it. It is built and verified on our machines, not deployed.
A 32-document product and engineering plan sets out ten roles, the flows between them, field-level data models, the API surface, document numbering, security and a verification plan, and gives about 77 web-app screens a stable ID. No application code has been written.
The screen specification covers 135 screens across 17 roles, each in its own file with layout, components, sample content, responsive behaviour and states, so it can become tickets without renaming. It is a proposal-stage prototype on mock data.
Common questions about PRD
How detailed should a PRD be before I ask for a fixed quote?
Detailed enough that every role, screen and money rule is named, along with the states each screen can be in: loading, empty and error. If the quote still depends on a phone call to explain how refunds or invoice numbers work, the document isn't finished.
Should the screens in a PRD have IDs?
It helps. On the Firetrix and Vyoma plans every screen carries a stable ID, so boards, routes, tickets and tests all refer to the same thing and nothing gets renamed between design and build.
Related terms
Planning a product and not sure where PRD fits? Ask us, or browse all 116 terms in the glossary.