A good brief does not need to be long or technical. It needs to explain the problem clearly enough that a development team can understand what success looks like and identify what they still need to ask. Vague briefs lead to vague estimates, and vague estimates lead to disputes later.
1. Describe the problem in plain language
Explain what is not working today and why it matters. “Branch managers spend two days each month compiling reports by hand” is more useful than “we need a reporting system”. The problem statement keeps everyone focused when design choices come up later.
2. Identify the people who will use it
List the user groups, roughly how many people are in each, and what each group needs to do. Note any practical constraints: shared computers, mobile-only users, limited connectivity, different languages or accessibility needs.
3. List what the system must do
Write the core tasks as short statements, for example:
- a sales officer records a new order and its delivery address;
- a supervisor approves orders above a set value;
- finance exports approved orders for invoicing.
Separate the essentials from the “nice to have” items. This makes it possible to plan a first release that is genuinely useful.
4. Mention existing systems and data
Which tools are already in use? Where does the data live today, and in what form? Integrations and data migration are often the least visible and most underestimated parts of a project.
5. State constraints and expectations
Include anything that limits the solution:
- deadlines that are genuinely fixed, and why;
- budget range, if you can share it;
- hosting, security or regulatory requirements;
- who will own and administer the system afterwards.
6. Define what “done” means
Describe how you will judge whether the project succeeded. Measurable outcomes are ideal, but even a clear description of the improved process helps both sides agree on acceptance.
What not to worry about
You do not need to choose the technology, design screens or write database tables. A capable team will propose those. Focus on the problem, the people and the outcome.
Expect questions
A good development partner will respond to a brief with questions, not just a price. Questions show that the team is thinking about risks and assumptions. A quote returned without any questions is usually built on guesses.
