What Each Blank in Your Software Brief Costs You

You do not need a technical specification to brief a software developer, and you do not need new vocabulary. You need seven things written down: outcome, users, current process, exceptions, data, constraints, and first result.

The structure is the easy part. It is also freely available - several good guides publish something close to it, and some hand you a template. What none of them tells you is what each blank costs. That is what this page is for: not the seven parts, but the price of leaving one out.

What is already covered - and what is not

It would be dishonest to write this as though the territory were empty. It is not. Searching for how to brief a software developer returns more than thirty guides, at least eight of which include a downloadable template.

Of the ones we opened on 24 August 2026, one is written explicitly for non-technical owners, sustains a single worked example - a dog grooming business - from top to bottom, and lists sections almost identical to ours. Another gives eight sections with must-have/should-have/nice-to-have prioritisation and unusually good coverage of deadlines and internal politics. A third goes further than either and explains how a vendor actually behaves when a brief is thin: it quotes what it was asked to build, and where detail is missing it silently picks the simplest implementation, picks the most common approach, or comes back with a question.

If you read that third guide and did what it said, you would be most of the way there. So the useful thing left to add is not another structure and not another template.

It is this: none of them maps a specific missing part to the specific thing that happens to your number. Consequences appear as general warnings and as one-off anecdotes, never part by part. And none of them treats exceptions as a section of its own - which is where estimates actually go wrong.

The cost of each blank

This is the table to keep. Each row is one part of the brief, what a bidder does when it is missing, and what that does to the number you get back.

Part left blank	What a bidder does with the gap	What it does to your number
Outcome	Invents a success criterion	Three bidders price three different definitions of “done”. The spread is not competition, it is confusion
Users	Guesses permissions and approval gates	The bidder who assumes everyone can do everything looks cheapest, until the first permission problem turns into paid work
Current process	Prices the happy path	The workaround you live with daily is invisible, so the estimate covers the work as imagined rather than the work as done
Exceptions	Prices the normal case only	The expensive cases arrive later as change requests, at change-request rates, after you have lost the advantage of competing quotes
Data	Defers migration and source-of-truth questions	Travels as unpriced risk, then reappears as paid integration work - usually the largest single surprise
Constraints	Assumes maximum freedom	You get a proposal that violates a boundary you never mentioned, and the rework is charged to you, not to the misunderstanding
First result	Prices everything at once	Maximum scope, lowest confidence, and every bidder pads against the uncertainty you did not resolve

Read down the right-hand column and the ordering becomes obvious. Outcome and first result move the number most, because they define what is being priced at all. Data is the one that surprises people. Exceptions are the one nobody writes down.

The seven parts, one at a time

Answer each in plain language, as the person who does the work would describe it.

1. Outcome. What should be true when this is done? Not “a CRM,” but “quotes become jobs and invoices without re-typing, and the profitability report is correct without a side spreadsheet.” Name the business outcome, not the product category.

2. Users. Who does this, and who decides what? Name roles and approval gates. Two people sharing one sheet is a different system from twenty people with three approval tiers, and the difference is mostly invisible until it is priced.

3. Current process. Walk through one complete path as it happens today - trigger, steps, who does what, where it breaks. Include the workaround. That workaround is very often the specification of what the system actually needs to do.

4. Exceptions. The two most common cases where the normal path does not apply. This gets its own section below, because it is the part most often skipped and the part that most reliably breaks an estimate.

5. Data. What facts does the work touch - clients, jobs, invoices, inventory - and which system is the source of truth for each? If the same fact lives in two places, say so. That is an integration question, not a detail.

6. Constraints. What must not happen? Regulatory boundaries, timing, budget, who cannot see what, what must not change about the existing process. Constraints narrow the solution space honestly, and a budget range is a constraint - withholding it does not get you a better price, it gets you a proposal aimed at the wrong size of problem.

7. First result. The smallest useful version that is genuinely complete: one path from trigger to outcome, with a way to know it worked. Name it, its acceptance condition, what is deliberately excluded, and the decision that follows once it is live.

Exceptions: the part nobody names

Every guide we opened has a features section. None has an exceptions section. In practice the exceptions are where the money is.

The normal path is easy to describe and easy to price, because it is the version you would demonstrate to a visitor. The exceptions are the ones you handle by hand, mention in passing, and forget to write down: the customer who is invoiced differently, the job that needs a manager’s override, the order that is part-delivered, the refund that has to reverse three things at once.

A bidder who has not been told about these prices the demonstration version. You then discover the exceptions one at a time, as change requests, at a point where you are no longer holding three competing quotes. That is the single most expensive omission available to you, and it costs nothing to prevent - you write down two of them.

Two is enough. Pick the exception that happens most often and the one that causes the most trouble when it happens. If they are the same, pick the next one.

Where the material actually comes from

Most bad briefs are not badly written. They are written by the wrong person, in the wrong room.

The owner writes the brief because the owner is commissioning the work. But the owner describes the process as it was designed, and the person who does it every day describes it as it has become. Those are different processes, and the gap between them is exactly where the exceptions and workarounds live - the two most expensive things to leave out.

So the material comes from a conversation, not from a blank document. Sit with the person who does the work and walk one real case, start to finish, using something that actually happened last week rather than a typical example. Typical examples are already cleaned up.

Three questions get most of it:

• “Show me what you did on this one.” Not what normally happens - this specific job. Follow the trail through whatever systems it touched, including the sheet and the messages.
• “When does that not work?” This is the exceptions question, and it usually produces an answer beginning “oh, unless…” That word is what you are listening for.
• “What would you have to tell a new person that isn’t written down anywhere?” Everything named in the answer belongs in the brief, and almost none of it will be in the current documentation.

Write it in their words. A brief written in the operator’s language survives contact with a developer far better than one translated into business vocabulary first, because the translation is where the detail goes missing.

A note on the data part

Data deserves more space than the others, because it is the part that most reliably produces a surprise invoice.

The question is not “what data do you have.” It is: for each fact the work touches, which system is the one that is right when two disagree? If a customer’s address is in the accounting package and the spreadsheet and someone’s email signature, one of those has to win, and deciding which is a business decision nobody can make for you.

Say also whether the old data has to come across. “We will start fresh” and “we need eleven years of history, searchable” are the same sentence to a reader and wildly different projects to a bidder. If history matters, say how far back and what you actually do with it - most people who ask for everything need the last two years and an archive they can search twice a year.

How we actually price a gap

Rather than generalise about how suppliers behave, here is what we do, so you can judge whether it is reasonable and ask others the same question.

When a brief is missing a part, we do one of three things, and only one of them is free for you.

We ask. If the missing part is cheap to establish - who approves, where the data lives - we ask before quoting. This costs you a day and nothing else, and it is what you want to happen.

We price the range. If the missing part could go two ways and both are plausible, we quote a range and say what moves it. A range with a stated reason is an honest number. A range with no stated reason is padding.

We assume, and write the assumption down. If a question would take you a fortnight to answer, we assume the common case, state the assumption in the proposal, and price that. This is the one that costs you money later, because an assumption you did not read is a scope boundary you did not agree.

What we try never to do is quote a single confident number against a thin brief. A firm price for an undescribed project is not reassurance - it means someone has made your assumptions for you and priced their own risk into the total. When you get one, ask which of the three things above happened.

What a good brief cannot do

Three limitations, stated plainly, because a brief is not a contract and treating it as one causes its own problems.

It cannot make an estimate accurate if the work is genuinely novel. For something nobody in the room has built before, the honest output is a small paid discovery phase, not a better brief.

It cannot protect you from a supplier who wants the work at any number. A brief makes quotes comparable; it does not make them honest. That is what references and a small first phase are for.

And it cannot survive contact with a changing business. A brief written six months before work starts describes a company that no longer exists. Write it close to when you intend to act.

Two illustrations

“We need a booking system.” The owner means: customers phone, the sheet crashes, confirmations are manual. One bidder hears the label and prices a calendar with a form. Another asks who books - customers or staff - through which channel, and what happens the day before, then prices online booking with automated reminders and a staff schedule view. Same phrase, different brief completeness: the second priced the problem, the first priced the label.

“We need something to track jobs.” One bidder prices a task list. Another asks what a job is here - a quote that becomes a job and then an invoice, or a standalone record? Who needs to see it, and what must not be seen? Where does it live today, and what has to move? The seven parts are the entire difference between the two numbers.

The one-page version, and what to do this week

The brief we use with clients fits on one page: seven headings, two or three sentences under each, and two exceptions named. It is not a document you write for a fortnight. It is a document you write in an hour, badly, and improve after the first conversation.

This week: write the outcome sentence and the first-result sentence. Those two move the number most. Then walk one complete path with the person who does it and write down two exceptions. That is most of the value, and you can do it before lunch.

Then put it in front of two bidders and ask each for scope, assumptions and exclusions against the same seven parts. The numbers become comparable for the first time, and comparing them is a separate skill this cluster covers on its own page.

FAQ

Do I need a technical person to help me write this? No. Every part above is a business question, not a technical one. If you find yourself reaching for technical vocabulary, you are probably describing a solution rather than a problem - which is the one thing that makes a brief worse.

What if I do not know what I want yet? Then say so, and describe the problem instead. A brief that honestly says “we know the outcome, not the shape” gets you a discovery conversation. A brief that guesses at a solution gets you a quote for the wrong thing.

Should I put a budget in the brief? Yes, as a range. Withholding it does not protect you - it produces proposals aimed at the wrong size of problem, which wastes everyone’s time including yours.

How long should it be? One page. If it runs to five, you are specifying rather than briefing, and the extra four pages will mostly be assumptions you have not tested.

Notes

• Live result set retrieved 2026-08-24 (en, GB proxy) via requests req_6a1acd60ee60 and req_c0aee24fdb82, both at zero budget; three pages opened and read in full. See research/live-result-set.md.
• This is a crowded territory: more than thirty comparable guides appear across the two result sets, at least eight with templates, and several written explicitly for non-technical readers. The page concedes this rather than claiming an empty field. What we found unserved is the per-part consequence mapping and exceptions as a named section.
• The section on how we price a gap describes Garaxe’s own estimating behaviour, in the first person deliberately. It is not a claim about how suppliers in general behave, and no success rate or client outcome is claimed anywhere on this page.
• One opened source published specific figures for quote variance. They are a single US-market anecdote and are deliberately not reproduced here; the mechanism is what transfers, not the numbers.
• No AI-assistant answer baseline was collected - the probe was unavailable on 2026-08-24 - so nothing here is a claim about what an assistant answers for this question.
• Autocomplete returned no suggestions and no People-Also-Ask questions were returned, so this page makes no claim about what owners search for.