The starting point
A clear brief does not need technical jargon. Describe the user, the task, and how you will decide that the work is ready.
Describe the problem before the feature list
Start with who will use the app and what they are trying to accomplish. Explain the current process, where it fails, and the change you want. A description such as 'members book a session and see their upcoming appointments' gives a developer more useful context than 'make an app like this competitor'.
Reference apps can illustrate a layout or interaction, but distinguish the parts you like from features you do not need. Your first release should solve a focused problem rather than copy another product's entire feature set.
Map one complete user journey
Write the steps from opening the app to finishing the main task. Include what happens when a user cancels, enters incorrect information, loses connection, or needs help. These paths affect the scope and testing effort.
Identify the roles that need access. A customer, staff member, and administrator may need different screens and permissions. State who manages the content and data behind the app; an administration interface should not be an unexpected addition late in the project.
- Primary user and the task they need to finish
- Essential screens and first-release features
- Roles, permissions, and administrator responsibilities
- Error, cancellation, and offline behaviour
- Data sources and third-party integrations
Set platform, budget, and launch constraints
Specify Android, iOS, desktop operating systems, or web support rather than asking for 'all platforms'. Mention expected devices, accessibility needs, languages, and any existing backend. Each requirement changes how the project is designed and tested.
Share your budget range and any fixed launch event. A developer can then suggest a smaller release or identify trade-offs early. Ask for an estimate based on stated assumptions, milestones, and exclusions rather than a delivery promise made before discovery.
Agree what finished means
For each important feature, describe an observable acceptance condition. For example: a customer can book an available slot, receives confirmation, and sees the booking in their account; an unavailable slot cannot be booked. That is easier to test than 'booking should work well'.
Set review points and explain who can approve designs and scope changes. Confirm which tests, supported devices, release preparation, and fixes are included. Third-party approval and account-verification processes should have clear responsibilities.
- Written scope and change-request process
- Feature acceptance criteria and review milestones
- Testing devices and supported operating-system versions
- Who owns developer, hosting, and third-party accounts
- Source-code ownership terms and handover contents
- Support duration, coverage, and additional-work pricing
Evaluate evidence and communication
Ask the developer to walk through relevant work, explain decisions, and describe what they personally delivered. A concept can demonstrate thinking and interface design, but should be identified as a concept rather than a customer result.
Before committing to a large build, consider a focused discovery or prototype milestone. The output should be something you can review: journeys, screens, technical assumptions, and a proposed release plan. BuildNerd uses those conversations to agree on a scope that both sides can understand.
Turn the brief into a conversation.
Tell us about your users, required platforms, and what the first release needs to do.
Discuss your project