Most briefs describe a product. The useful ones describe a problem, the boundaries around it, and what would count as solving it. The difference shows up immediately in the quotes you get back.
Why the brief decides the estimate
An estimate is a forecast about unknowns. Every question the brief leaves open is an unknown the supplier must price, and there are only two ways to price an unknown: pad for it, or ignore it and discover it later at your expense.
So a vague brief does not produce a cheap quote. It produces an unreliable one, and quotes that vary by a factor of three usually indicate a brief that let each supplier imagine a different project.
There is a well-known claim that defects get dramatically more expensive the later they are found. Barry Boehm’s 1976 work on TRW and IBM data suggested field defects cost 50 to 200 times more than early ones, and the figure has been repeated ever since. Later studies are more modest: Shull and colleagues found roughly 4 to 5 times more expensive in testing than in design, and McConnell synthesised industry data around 10 to 25 times for defects reaching production.
Worth being straight about this: the specific multipliers have been seriously criticised. Laurent Bossavit’s The Leprechauns of Software Engineering traced the citation chain and found the underlying evidence thin. The direction, that fixing something after it is built costs more than deciding it before, is well supported and matches everyone’s experience. The precise numbers are folklore. Treat anyone quoting “100x” with the same scepticism you would apply to any suspiciously round claim.
The six things that actually move a quote
1. The decision or workflow being supported. Not the feature list. What happens today, who does it, what triggers it, what the states are, and what happens on the unhappy paths. If you can describe one complete journey end to end, including the awkward cases, you have done most of the work.
2. Every system it must touch. For each one: is there an API, is there documentation, is there a non-production environment, and who internally can authorise access. Integrations are the single largest source of overrun, and this is the cheapest thing you can hand a supplier.
3. The state of the data. Not a schema diagram. Real record counts, and an honest note on quality. How many rows have a null in a field the new system will require. How many duplicates. Suppliers who see this quote better and pad less.
4. Volumes and growth. Users today, transactions per day, largest file, peak periods. Architecture that serves two hundred users costs less than architecture that serves ten thousand, and building for a scale you are guessing at is a common way to overspend.
5. Compliance duties. Payment data, health records, personal data at volume, sector rules. These carry real work: access control, audit logging, retention, encryption, testing. Naming them up front is far cheaper than retrofitting them.
6. Who decides, and how fast. Name the person who can answer questions, and be honest about turnaround. Decision latency is usually the largest schedule cost on a project and it sits on your side of the table.
Specify the problem, not the solution
The most common brief error is arriving with the answer already chosen: a technology, a screen design, a database. Sometimes that is right and constraints are legitimate, in which case say so and say why.
Where it goes wrong is when a preference gets written as a requirement and nobody can tell the difference. Suppliers then price the preference instead of the problem, and the useful conversation, the one where someone who has built this before tells you there is a cheaper way, never happens.
Separate the two explicitly. “Must integrate with our existing Dynamics instance” is a constraint. “Should be built in React” is usually a preference, and labelling it honestly invites the disagreement you are paying for.
What to leave out
Exhaustive screen-by-screen descriptions. They take weeks, go stale immediately, and encourage suppliers to quote for building exactly what you drew rather than what works.
Effort estimates. If you knew, you would not be asking. Stating a number anchors every response to it.
Your budget, at first. Reasonable people differ here. Our view: withhold it for the first round so you can see what each supplier thinks the work costs, then share it to shape scope. Sharing too early turns every quote into the same number.
A brief you can finish
Two to four pages covering the six items above beats a forty-page specification that never gets written. If a section is genuinely unknown, write “unknown” rather than guessing. A supplier can price an acknowledged unknown, usually by proposing to investigate it first. A supplier cannot price a confident statement that turns out to be wrong.
That is also what a discovery phase is for. If more than one or two of the six are unknown, the honest answer is that nobody can quote the build yet, and the right first purchase is the investigation rather than the project.
More on what a trustworthy quote contains in choosing a development partner, and on reading the resulting numbers in what custom software actually costs.
If you have a draft brief and want to know what is missing before you send it out, send it to us. We will tell you what we would need to ask, which is useful whoever you end up hiring.
Common questions
What should a software requirements brief include?
The workflow or decision being supported including the unhappy paths, every system it must integrate with and whether each has an API and a test environment, the real condition of the data, expected volumes, any compliance duties, and who can make decisions and how quickly. Two to four pages covering those beats a long specification that never gets finished.
Should I include my budget in the brief?
Not in the first round. Withholding it lets you see what each supplier independently thinks the work costs, which is informative. Share it afterwards to shape scope. Sharing at the outset tends to make every quote arrive at the same number.
Why do quotes for the same brief vary so much?
Because the brief left the expensive questions open, so each supplier priced a different set of assumptions. Integrations, data condition and compliance duties are the usual culprits. Quotes converge quickly once those three are specified.
Sources
- Boehm (1976), on TRW and IBM project data, reported field defects costing 50 to 200 times more to correct than those caught early.
- Shull et al. (2002) found defects roughly 4 to 5 times more expensive to fix in testing than in design. McConnell (2004) synthesised industry data around 10 to 25 times for defects escaping to production. Jones (2008) reported multipliers from 1x to 100x depending on defect type and detection stage.
- Laurent Bossavit, The Leprechauns of Software Engineering, examined the citation history behind these figures and found the underlying evidence weak. The general direction is well supported. The specific multipliers should not be treated as measured fact.
Written September 2026.
