Every supplier prices uncertainty. A vague brief is expensive before anyone writes a line of code, because the quote has to cover everything it might turn out to mean.
You do not need a technical document. You need a clear one. The goal is to remove ambiguity about what the software must achieve, while leaving the supplier free to decide how.
Get that balance wrong in either direction and it costs you.
Why vagueness costs money
A supplier reading “we need a customer portal” has to price a range. At the small end it is a login and an order list. At the large end it is documents, payments, permissions, notifications and an admin system.
They cannot quote the small version in case you meant the large one. So they quote somewhere above the middle, add a risk premium, and you pay for uncertainty that a page of writing would have removed.
The Panorama 2026 ERP data makes the same point from the other direction: among projects that went over budget, 51% saw scope grow beyond the original plan and 54.9% needed technology that was only discovered after the project began.
Specification is the cheapest risk reduction available to you. A week of your time can remove tens of thousands of pounds of priced-in uncertainty.
The mistake that costs more than vagueness
Specifying the solution instead of the problem.
| Specifying the solution | Specifying the outcome |
|---|---|
| “We need a dropdown on the booking screen showing available vans” | “Staff must not be able to double-book a van. They currently do this about twice a week and it costs us a delivery slot each time.” |
The first locks in a design decision made by someone who has not seen the data or the constraints. It may be the wrong answer, and the supplier will build it anyway because you asked.
The second gives a measurable problem, its cost, and freedom to find the best solution — which might be a dropdown, or might be a validation rule that makes the problem impossible.
Describe the outcome you need and the constraints you have. Leave the mechanism open.
Who should write it
Not the person you might assume.
Not solely the project sponsor. They know why the project matters and frequently not how the work is actually done. Specs written only from the top describe the process as management believes it runs.
Not solely the person doing the work. They know the detail and often cannot see which parts are essential versus habitual. Specs written only from the floor encode current practice including its inefficiencies.
Both, with someone holding the pen. One person writes, interviewing the others. That person needs enough authority to resolve disagreements about what the process should be, because the spec will surface two departments doing the same thing differently — and that is a decision, not a documentation problem.
Involve the newest person on the team. Someone who joined in the last year can still see which steps are genuinely necessary and which are habit. That perspective disappears after about eighteen months.
Allow a week of calendar time, not a week of effort. The writing is a day or two. The rest is people being available and disagreements being resolved.
The structure
1. The problem, in business terms
One to two pages. The most important section and the one most often skipped.
- What happens today, step by step
- What goes wrong, how often, and what it costs — hours, errors, lost sales, risk
- Who is affected
- What you have already tried
Put numbers on it. “Month-end takes four days, of which roughly two and a half are assembling data by hand” tells a supplier more than three pages of feature requests.
If you cannot state the cost of the problem, pause. A problem without a cost does not justify a build.
2. Who uses it
For each type of user: who they are, their technical confidence, what they need to accomplish, how often, and on what device.
“Warehouse staff, mostly on phones, often with gloves on, in poor signal” changes the build fundamentally. That single sentence is worth more than a feature list.
3. What it must do — as outcomes
Write these as things a user must be able to achieve.
“A customer must be able to see the current status of every order they have placed in the last 12 months, without phoning us.”
Each one testable. Each one an outcome rather than a mechanism.
Group them into must-have, should-have and nice-to-have, and be honest. If everything is must-have, the supplier cannot help you phase the work, and phasing is how you get something live early and spend less overall.
4. What it must connect to
The section that most affects price, and the one most often thin.
For every system involved:
- What it is and which version
- Who controls it — you, or a vendor
- Whether it has an API, and whether you have ever used it
- Which direction data flows
- How current the data must be
If you do not know whether an API exists, say so. An honest unknown is cheaper than an optimistic assumption, because the supplier can price investigating it.
5. Your data
- What you have, roughly how much, and where it lives
- How clean it is — honestly
- What must be migrated and what can be archived
- Anything with special handling requirements
Be honest about data quality. Migrating 40,000 clean records is a day. Migrating 40,000 records where the same customer appears four times under three spellings is weeks. Pretending otherwise does not make the work shorter, it makes the overrun a surprise.
6. Constraints
- Hard deadlines, and what is driving them
- Budget range — see below
- Regulatory requirements: UK GDPR, sector-specific rules, accessibility
- Technology you must use or must avoid, and why
- Where data may and may not be stored
7. What success looks like
How you will judge, in six months, whether this was worth doing.
“Month-end takes under a day. Double-bookings drop below one a month. Nobody retypes order data between systems.”
This focuses the whole project and gives you a basis for accepting the work.
8. Explicitly out of scope
Short, and disproportionately valuable. “We are not replacing the accounting system. We are not building a mobile app in this phase.”
Boundaries make quotes comparable and prevent the most common cause of mid-project friction.
Should you state your budget?
Yes. The argument against — that suppliers will quote up to it — assumes you are powerless, and you are not.
What happens without a budget: three quotes of £15,000, £60,000 and £180,000, because each supplier guessed a different project. You cannot compare them and you have learned nothing.
What happens with one: each supplier tells you what is achievable within it, or says it is not enough. You get comparable proposals and an honest answer about feasibility.
Give a range — “£30,000–£50,000, with flexibility for the right approach” — and ask what each supplier would do with it. The responses will differ enormously, and those differences are the actual information.
If you are worried about being quoted up to your number, send the same brief to three firms. Published prices make this easier — you can check whether a quote is in a sane band before you ever speak to anyone.
How long should it be?
Five to fifteen pages for most projects. Less than five and ambiguity remains. More than twenty and you are specifying solutions rather than outcomes.
A 60-page document is usually a sign that someone has designed the software in prose. That costs money twice: once to write, and again when the supplier has to work around decisions made without seeing the data.
What you do not need to write
- Database design. That is the supplier’s job and they will do it better.
- Technology choices, unless you have a genuine constraint such as an existing team’s skills.
- Screen designs, unless you have a strong view. Wireframes help; pixel-perfect mockups lock in decisions early.
- Technical architecture. Describe the constraints, not the solution.
- Exhaustive edge cases. Name the ones that matter commercially and let discovery find the rest.
Wireframes: how much is useful
The question that comes up every time, with a clearer answer than “it depends”.
Sketch the three hardest screens. Not every screen — the ones where a lot of information must coexist, or where the sequence is genuinely complex. Those are where a picture removes more ambiguity than a page of prose.
Keep them deliberately rough. Pencil, or a whiteboard photograph. Rough sketches invite improvement; polished mockups invite compliance, and you want the supplier’s judgement rather than their obedience.
What a sketch should show: what information is on the screen, roughly what matters most, and what the user does next. Not colours, fonts, spacing or component styling.
What polished mockups cost you: they lock in layout decisions made before anyone has seen the data volumes. A table designed for five rows behaves differently with four hundred. A supplier who has seen the data will design that better than you can in advance.
The exception: if you already have a design system or brand guidelines, supply them. That is a constraint rather than a solution, and it genuinely helps.
Before you send it
Read it as if you knew nothing about your business. Every acronym, every internal term, every “obviously” needs explaining.
Show it to someone who does the work. Not just the sponsor. The person who processes the orders will spot three things that are wrong.
Check that every requirement is testable. If you cannot say how you would verify it, it is not specific enough.
Check you have not solved the problem for them. Count how many requirements name a mechanism. Rewrite those as outcomes.
Send the same document to three firms. Different briefs produce incomparable quotes.
Common mistakes, and what they cost
Six that appear repeatedly, with their price.
Writing the solution instead of the problem. Locks in a design decision made without seeing the data. The supplier builds it because you asked. Cost: you get what you specified rather than what you needed.
Everything marked must-have. Suppliers cannot help you phase, so you get one large quote instead of a staged plan. Cost: a bigger first invoice and value arriving later.
Being vague about integrations. Each unknown integration is priced as a range, and the range is wide. Cost: a risk premium of thousands, for information you could have supplied in a paragraph.
Optimism about data quality. Everyone says their data is “pretty good”. The migration quote is based on that, then revised. Cost: the most common overrun in any project, and the least pleasant conversation.
No out-of-scope list. No boundary, so no defence against growth. Cost: 51% of over-budget ERP projects saw scope grow.
Not stating the budget. Three incomparable quotes for three imagined projects. Cost: weeks, and you still know nothing.
Each of these takes a paragraph to avoid and thousands to fix. The hour spent on the spec is the highest-return hour in the entire process.
What happens next
A good supplier will come back with questions, not a quote. The quality of those questions is the single best signal you will get about them before any money changes hands.
Questions worth hearing: What happens when two people do this at once? What should happen if the integration is down? Who decides when there is a dispute? How many of these records are actually active?
A supplier who quotes immediately from a brief without asking anything has either built it before, or has not read it properly. It is worth finding out which.
A one-page template
If fifteen pages feels like too much to start, write this. It is enough to get useful responses and it takes an afternoon.
THE PROBLEM
What happens today, step by step:
What goes wrong, how often:
What it costs us per year (hours × 52 × fully loaded rate):
What we have already tried:
WHO USES IT
[Role] — [technical confidence] — [what they need to achieve] —
[how often] — [on what device]
WHAT IT MUST ACHIEVE (outcomes, not mechanisms)
Must have:
1.
2.
3.
Should have:
Nice to have:
WHAT IT CONNECTS TO
[System] — [version] — [who controls it] — [has an API?] —
[have we ever used it?] — [which direction does data flow?]
OUR DATA
What we have, roughly how much, where it lives:
How clean it is (honestly):
What must be migrated vs archived:
CONSTRAINTS
Deadline, and what is driving it:
Budget range:
Regulatory (UK GDPR, sector rules, accessibility):
Technology we must use or avoid, and why:
SUCCESS IN SIX MONTHS
We will know this worked if:
EXPLICITLY OUT OF SCOPE
We are not:The two lines that do the most work are the annual cost of the problem and the out-of-scope list. The first tells a supplier what the project is worth; the second gives them a boundary to quote against.
Frequently asked questions
Do I need a technical specification to get a software quote?
No. You need a clear description of the problem, the users, the required outcomes, the systems involved and your constraints. Technical design is the supplier’s job.
How detailed should a software brief be?
Five to fifteen pages for most projects. Detailed on outcomes, constraints and integrations; light on mechanism and technology.
Should I tell suppliers my budget?
Yes, as a range. Without one you get wildly different quotes for different imagined projects and no way to compare them. With one you get comparable proposals and an honest view on feasibility.
What if I don’t know what I want?
That is normal and it is what paid discovery exists for. A short discovery engagement — typically £3,000–£8,000 — produces the specification and a costed plan, and the output should be yours to take anywhere.
How do I stop scope creep?
Write down what is out of scope, group requirements into must/should/nice, define testable acceptance criteria, and agree a written change process before work starts. Changes are normal; unpriced changes are the problem.
Should I include wireframes?
Rough ones help enormously and cost you little. Polished designs can lock in decisions before anyone has seen the data. Sketch the hard screens, leave the rest.
How many suppliers should I send it to?
Three, with an identical brief. More than three rarely adds information and costs you weeks.
Written by Jas Singh. Last updated 8 October 2026.
Scope and budget overrun figures from the Panorama Consulting 2026 ERP report (170 organisations, January 2025 – January 2026) as reported by secondary sources; cited as directional.
