Start with a complete workflow
Describe who starts the work, what information they need, which decisions they make and what a completed task looks like. Include exceptions: cancelled orders, missing records and users with restricted access. A screen list alone will miss these requirements.
Separate the first release from later ideas
Choose one end-to-end workflow that makes the first release useful. Record integrations, imports, roles and reporting alongside the screens. Put optional features in a separate list so estimates can distinguish essential work from future expansion.
Write acceptance checks before choosing a stack
For each important task, define an observable result and the failure state. For an approval workflow, check who can approve, what is recorded and what happens when the same request is submitted twice. Include keyboard and phone use in the review.
Plan ownership after launch
Identify who will own hosting accounts, source access, backups, deployment and support. Ask for setup instructions and a handover walkthrough. Discuss licensing explicitly: an open-source direction does not make private business data public.
Bring this to your project brief.
- A sample workflow and anonymized records
- Roles, integrations and first-release boundaries
- Acceptance checks and a maintenance owner
Use general descriptions or anonymized examples. Do not put credentials, personal records or confidential documents into the brief.
Prepare your project brief