Three quotes come back at fifteen, forty and ninety thousand. Everyone assumes the suppliers differ wildly. Usually they were each guessing at a different interpretation of the same ambiguous document, and the spread is the size of the ambiguity rather than the size of the disagreement.
A good software brief is not long and it is not technical. It answers what has to be true when this is finished, for whom, and how you will know. Most briefs answer a different question, which is what screens they imagine, and that is precisely the part a supplier is better at than you.
Describe outcomes, not screens
The most common and most expensive mistake, and it feels like being helpful.
A brief that says a dashboard with a sidebar showing jobs, filterable by status, with a modal for editing has specified a solution. The supplier now builds that, and if it turns out that what your team actually needed was a printed sheet for the van, you have paid for a dashboard nobody opens. You have also removed the supplier's ability to suggest something better, which is a large part of what you are paying for.
The same requirement as an outcome: a field engineer arriving at a site can see what they are meant to do there and record what they did, including when there is no signal. Now a supplier can propose, question, and price honestly, and you will find out that the offline requirement is the expensive part rather than the sidebar.
What a software brief has to contain
Six things. Everything else is optional and most of it is noise.
- The problem, in your own words, with a number attached. Not what you want built. What is going wrong and what it currently costs, in hours, mistakes or lost work. This is the single most useful paragraph in the document and the one most often missing.
- Who uses it, and where. Three office staff on laptops is a different product from forty drivers on phones in a yard. Say how many, how technical, and in what conditions.
- What has to be true when it is done. A short list of things a person can do, each phrased so you could watch someone attempt it and agree whether it worked.
- What it must connect to, by name. Your accounting package, your CRM, the machine in the workshop. Name the products and say which version, because this is frequently the largest cost driver and it is invisible unless you say it.
- The constraints that are real. A date that genuinely matters and why. A budget range. A regulation. Anything that has already been decided and is not up for discussion.
- What already exists. The spreadsheet, the current system, the previous attempt. Attach it. A supplier learns more from your actual spreadsheet than from three pages describing it.
What to leave out
- Technology choices, unless you have a real constraint such as an existing team who must maintain it. Naming a framework in a brief narrows your options and rarely improves the outcome.
- Screen designs and wireframes, unless you have tested them with users. An untested design in a brief becomes a specification nobody questions.
- Every feature you can imagine. A wish list produces a wish-list price. Separate what must work at launch from what would be good later, explicitly, and expect the second list to shrink once the first is priced.
- Vague ambitions. Modern, intuitive, scalable, user-friendly. These cannot be built, cannot be tested and cannot be priced, so they add length without adding meaning.
- Detailed database structures, unless you are integrating with something that already has one.
The section everybody omits
Write down what you do not want, and what would make the project a failure even if it were delivered on time.
This is unusual, it takes ten minutes, and it changes the quality of the responses more than anything else on this page. It might say: it must not require a laptop, our staff will not use it. It must not need us to change our invoice numbering. It must not take more than a day to train someone. If nobody uses it within a month, it has failed regardless of what was built.
A supplier reading that knows what to avoid, and a supplier who ignores it has told you something important before you have paid anything.
How long it should be
| Project | Brief | Then |
|---|---|---|
| A small piece of work, a few thousand | One page, or a clear email | Just ask. A formal brief costs more than the ambiguity would. |
| A defined system, tens of thousands | Two to four pages, using the six headings above | Send it to three suppliers and compare the questions they ask, not just the prices. |
| Something substantial, six figures | Four to eight pages, plus your existing spreadsheets and screenshots | Pay for a short discovery before the full quote. It is cheaper than the misunderstanding. |
Longer is not better. We have priced twenty-page briefs that told us less than a good one-page email, because length was being used to substitute for decisions nobody had made.
Send it to three, and read the questions
The brief is only half of the exercise. What comes back tells you as much as what you wrote.
- A supplier who asks nothing is a warning, not a convenience. Every real project has ambiguities and silence means either they have not read it or they intend to resolve them their own way later.
- Compare the questions across suppliers. Where two ask the same thing, your brief is genuinely unclear and you should fix it for everyone rather than answer twice.
- A supplier who proposes something smaller than you asked for is usually worth listening to, since they are reducing their own invoice.
- Watch for the assumptions page. How a supplier fills the gaps you left is the most honest preview of how they will behave during the project. Red flags in a software proposal covers what to look for.
A structure you can fill in this afternoon
If it helps to have something to type into, this is the shape we would want to receive. Each heading is a paragraph, not a chapter.
- The situation now. What happens today, who does it, and roughly how long it takes. Two or three sentences of plain description.
- What it costs us. Hours a week, mistakes a month, work turned away, customers annoyed. A number, even an estimated one, is worth more than an adjective.
- Who would use the new thing. How many people, how technical, on what devices, in what environment. Mention if any of them are outside your organisation.
- What they must be able to do. A numbered list of five to ten things, each one testable. If you cannot imagine watching someone try it and agreeing whether it worked, rewrite it.
- What it must connect to. Named products, and who owns the accounts. Say if you do not know, because that is a finding rather than a gap.
- What must not happen. The failure conditions. The thing that would make this a waste even if delivered perfectly.
- Fixed constraints. A date and why, a budget range, a rule you have to follow. Say which of these are genuinely fixed and which are preferences, because suppliers cannot tell.
- Attached. The current spreadsheet, screenshots of the existing system, an example of the document you produce today. Real artefacts, not descriptions of them.
That is typically two to three pages when written honestly, and it will get you more comparable quotes than a twenty-page specification, because every supplier is answering the same questions rather than inventing their own.
When a prototype beats a brief
If you are finding this genuinely hard, that is information rather than a failure of writing. Some projects cannot be described accurately in advance because nobody yet knows what they should do.
In that case, a clickable prototype is a better specification than any document: real screens, a real flow, nothing working underneath, at roughly $4,000 to $12,000 over two to three weeks. You can put it in front of the people who will use it, change it cheaply while it is still rectangles, and hand the result to whoever builds it. That is what our prototyping work is for, and it removes most of the ambiguity that makes quotes vary so wildly. How much does an MVP cost covers where that sits in a wider budget.
Not for you if
The test we apply to any brief we receive: could we build the wrong thing while following it exactly? If the answer is yes, we ask, and the question usually improves the project rather than delaying it. If a supplier does not ask, they will build it, and both of you will discover the misunderstanding at the demo with two weeks of work behind it.