Does a Wavesteam contract include PRDs, prototypes, and technical design documents?
Wavesteam provides PRDs, prototypes, design source, API definitions, and technical plans when the contract lists them. Before signing, the normal output is scope and estimating assumptions. A complete PRD, interactive prototype, UI source, and architecture are paid work and should have a version, format, milestone, approver, and source-file requirement in the annex.
“All documentation included” is not useful because a two-week enhancement and a multi-system platform require different depth, and a complete PRD cannot truthfully exist before discovery. Wavesteam writes documents that support decisions, implementation, testing, and takeover rather than maximizing page count. A client needing a supplier-neutral package for tender can commission a separate discovery and product-design phase; that portable output should not be disguised as free presales.
| Stage | Typical documents | Purpose | Contract treatment |
|---|---|---|---|
| Presales and estimate | Objective, first scope, assumptions, exclusions, dependencies, rough milestones | Establishes the quote boundary | Quote/contract annex, not called a complete PRD |
| Requirements and design | PRD, workflows, roles, fields, states, exceptions, prototype, UI rules | Confirms what is built and used | Revision rounds, page/flow scope, source files, approval point |
| Technical design | Architecture decisions, model, APIs, integrations, permissions, deployment, non-functional needs | Explains implementation and operation | List risk-relevant mandatory artifacts, not empty boilerplate |
| Test and launch | Test scope, defects, release, monitoring, backup, rollback, training | Proves deployability, recovery, and operation | Link to release acceptance and warranty start |
| Final handover | Current document index, repositories/releases, accounts, open issues | Enables client or replacement team takeover | Editable format, location, supported version, final update date |
A PRD covers users, rules, normal and exceptional flows, roles and permissions, fields and states, dependencies, data definitions, and acceptance scenarios. It is neither a screenshot manual nor permanently frozen; changes carry versions, reasons, impact, and approval. ISO/IEC/IEEE 29148 provides a reference for requirements activities and artifacts, while an SME project should select relevant content rather than reproduce a heavy template.
Prototype work validates information structure, task path, and feedback early. Low fidelity confirms the workflow before high-fidelity visual design. Loading, empty, error, denied, long text, and mobile states matter too. The agreement states pages or key flows, revision rounds, Figma/Axure or another format, editable source, and licences for fonts, images, and components. Prototype approval is not software acceptance; real data, performance, and APIs still require implementation tests.
A technical design is more than a list of frameworks. According to risk, it records module boundaries, upstream/downstream systems, data model, identity and access, APIs/events, third parties, migration, capacity assumptions, logs and monitoring, recovery, and deployment topology. Supply an OpenAPI document that matches the deployed release. Short architecture decision records explain important alternatives and consequences to a future team.
Documents remain version-aligned. PRD, prototype, and API each have an owner, state, and updated date. Post-milestone edits become visible changes rather than replacing history. Final handover indexes location, applicable system version, and unresolved issues. PDF alone may be insufficient: artifacts the client must maintain should also use agreed editable or machine-readable formats.
“Included in the price” means the effort was estimated, not that documentation is free. A complete pre-tender PRD is an independent consulting deliverable. A mature client PRD may reduce discovery or expose more complexity. Extra revision rounds, changed core flows, and new platforms use change control.
Acceptance does not stop at file existence. Sample live functions and compare PRD rules, prototype states, API fields, tests, and the actual system. Ask client engineers to deploy from the instructions and operators to configure from the guide. Documents that cannot support these tasks need remediation. The Wavesteam service process and Transparent Delivery Standard are checklist inputs; the project annex is the final obligation.