A vague brief gets a vague quote. Then the surprises arrive halfway through the build, when changing course costs the most. A good brief does not need technical language. It needs to say what you want, who it is for, and how you will know it is done. Here is how to write one.
Start with the goal and the users
Open with one or two sentences on why this project exists. What problem does it solve, and what changes for your business when it works? 'Customers should be able to book and pay for a session without calling us' tells a developer far more than a list of screens. The goal also helps the developer push back usefully. If a feature does not serve the goal, they can say so before you pay for it.
Then list the types of users and what each one needs to do. Keep it plain.
- Customers browse products, place orders and track delivery
- Staff update stock and mark orders as shipped
- You view sales reports and manage staff accounts
Say where they will use it: phone, desktop or both. Mention anything unusual, such as users on slow connections or a need for more than one language. These details change the estimate more than most people expect.
Separate must-haves from nice-to-haves
This is the part that saves the most money. Put every feature into one of two lists. Must-haves are the things without which the project fails. Nice-to-haves are the things you would like if time and budget allow.
Developers can then quote the must-haves firmly and price the rest as options. You get a clear first version, and you decide on extras with real numbers in front of you. Be honest with yourself here. If everything is a must-have, nothing is.
Show examples and name the integrations
Examples beat descriptions. Link to two or three sites or apps that do something close to what you want, and say what you like about each: the checkout, the search, the dashboard layout. Screenshots or rough sketches on paper work too.
Then list every outside system the project has to talk to. Payment gateways, SMS or email providers, accounting software, a CRM, shipping partners, an existing database. Integrations are often where estimates go wrong, so name each one and say whether you already have an account. If there are several, it is worth reading about our API integration work.
Access, acceptance criteria and deadlines
Access. Say what already exists and what the developer will need: hosting, domain, an existing codebase, app store accounts, design files. Keep these accounts in your name and grant access, rather than letting a developer create them for you.
Acceptance criteria. For each must-have, write one or two sentences describing what done looks like. 'A customer can reset their password by email and log in with the new one' is testable. 'Login should work well' is not. These sentences become your checklist at handover.
Deadlines. Give the real date and the reason behind it. A trade show, a seasonal sale or a funding meeting is a hard deadline. 'We would like it soon' is not. Developers plan differently around each, and some will suggest cutting scope to hit a fixed date.
A short brief template
Copy this and fill in each line. One or two pages is plenty.
- Goal: the problem this solves and what success looks like
- Users: who uses it, what each type needs to do, on which devices
- Must-haves: the features the first version cannot ship without
- Nice-to-haves: features to price separately as options
- Examples: links or screenshots, with what you like about each
- Integrations: every outside system, and whether you have an account
- What exists already: code, designs, hosting, domain, content
- Acceptance criteria: one testable sentence per must-have
- Deadline: the date and why it matters
- Budget range: even a rough one helps developers suggest the right scope
- Contact: who answers questions and approves work
Send it, then expect questions
A good developer will come back with questions. That is a good sign, not a delay. The answers usually tighten the quote and remove surprises later. A developer who quotes without asking anything has probably filled the gaps with guesses.
The same brief works whether you send it to a freelancer, an agency or a dedicated developer, which makes quotes easy to compare. Our guide to freelancer vs agency vs dedicated developer helps you choose who to send it to. A clear brief also points to the right hiring model. If you can write the acceptance criteria today, a project based engagement with a fixed quote usually fits. If not, hourly or monthly may suit better. When your brief is ready, send it to us, or read what to check before hiring a developer first.
Tell us what you are building. We reply by email, usually the same working day.
