Key takeaways
- A brief describes the problem, the people affected and what success looks like. It is not a feature list.
- One page that a stranger can follow is better than twenty pages nobody finishes.
- Say what is fixed and what is open. Suppliers can only be honest about cost and time if they know which is which.
- Write down what is out of scope. It prevents more arguments than anything else in the document.
Why does the brief matter?
Every software quote is a reaction to what the supplier thinks you asked for. A vague brief gets a vague quote, and two suppliers can read the same sentence and price two different projects. That is why quotes for the same job often look so far apart.
A good brief does not need technical language. It needs clear thinking about the problem, written down. Our guide to what drives the cost of custom software explains why scope is the biggest lever on price. The brief is where you set it.
What should a software project brief include?
You can cover almost everything on one or two pages with these seven headings.
1. The problem
Describe what is slow, risky, expensive or impossible today. Write about the situation, not the solution.
"Our team re-types orders from emails into three systems, and mistakes reach customers" is a problem. "We need an order portal" is a solution that may or may not fit.
2. Who it is for
List the groups of people who will use it or be affected by it: staff, customers, suppliers, managers. For each, say roughly how many there are and what they need to do. External users usually mean more design, security and support work than internal ones.
3. What success looks like
Say how you will know it worked. Use something you can observe, such as fewer manual steps, faster turnaround or fewer errors. Avoid targets you cannot measure or have not measured before.
4. What it must do first
List the few things the first release must do for the project to be worth it. Everything else goes in a "later" list. This is the single most useful step for controlling cost, and it is how a good MVP is scoped.
5. What it connects to
Name the systems the software has to work with: accounting, a shop, a CRM, a spreadsheet, a payment provider. Say what you know about each, including who looks after it. Integrations are often where estimates go wrong, because they depend on systems you do not control.
6. Constraints
Include anything that limits the solution:
- budget range, or at least a ceiling you cannot go above
- a date that cannot move, and why
- legal or regulatory duties, such as handling personal data under UK GDPR
- technology you must or must not use
- who needs to approve decisions
If you do not know the budget, say so. Giving a range helps a supplier propose something that fits rather than guess.
7. What is out of scope
State what you are not asking for. This feels unnecessary until a disagreement starts. A short list of exclusions, such as "no mobile app in the first release" or "no data migration from the old system", saves a great deal of discussion later.
What should you leave out?
- Detailed screen designs, unless you already have them. Suppliers should shape these with you.
- A specific technology, unless there is a real reason. Ask for a recommendation and the reasons for it.
- Every possible feature. A long list makes the important items harder to see.
- Confidential material you would not share with an unsuccessful bidder. Share more detail once you have chosen a supplier and signed an agreement.
How do you know the brief is ready?
Give it to someone who has not been involved and ask them to explain it back to you. If they cannot say what problem is being solved and for whom, rewrite it.
Then check these points:
- Does it say what you want to be true afterwards, not only what you want built?
- Would two suppliers price roughly the same project from it?
- Does it say what is fixed and what is open to discussion?
- Does it state who makes decisions on your side?
What if you are not ready to write a brief?
Sometimes the honest answer is that you cannot finish the headings yet. You may know the problem but not the solution, or the reverse. That is normal, and it is what a short discovery stage is for. See technical discovery explained for how it turns a rough idea into a written scope.
Once you have a brief, use it to compare suppliers on equal terms. Our guide on how to choose a software development company lists what to ask each one.
Frequently asked questions
How long should a brief be? One to two pages is enough for most projects. Add detail where there is real complexity, such as unusual integrations or regulation.
Should I include a budget? A range or ceiling is helpful. Suppliers who know it can propose options that fit, and you can compare what each would deliver for the same figure.
Can I send the same brief to several suppliers? Yes, and it is the fairest way to compare them. Share the same information and answer their questions to everyone.
What if the brief changes once work starts? It will, and that is acceptable. Agree how changes are decided and priced before starting, so a change is a conversation rather than a dispute.
If you would like help turning a rough idea into a clear scope, our custom software development service begins with that, and you can contact us to start.