Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
  1. Home
  2. Blog
  3. How to Write a Brief That Gets You Comparable Quotes
Hiring & Budgets

How to Write a Brief That Gets You Comparable Quotes

How to write a software brief that gets comparable quotes: the eight sections, describing workflows as steps, stating a budget and the awkward details.

Updated 2 min readBy SpiderHunts Technologies

Free estimateNo obligation

Get a free estimate

Tell us what you need. A senior engineer reads every enquiry.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →

Quick answer — TL;DR

Wildly varying quotes usually mean an ambiguous brief, not dishonest suppliers. Include the problem, the users, the workflows, the systems it must touch, your constraints, your budget range and what success looks like. Stating a budget range gets you better proposals, not worse prices.

Suppliers quote what they imagine you meant

Give five suppliers a vague brief and you get five different projects priced. One assumes a simple version, one assumes an enterprise build, and you cannot compare any of them.

The brief's job is not to specify the solution. It is to remove enough ambiguity that everyone is pricing the same thing.

The eight sections

  1. The problem, in business terms. What happens today, what it costs, why now.
  2. Who uses it — roles, rough numbers, technical confidence, internal or external.
  3. The workflows, described as steps. This is the most important section and the one most often missing.
  4. Systems it must touch, named, with whether they have an API if you know.
  5. Constraints — deadlines, regulatory requirements, existing technology you must keep, data residency.
  6. Success criteria, measurable. “Order entry under two minutes” beats “more efficient”.
  7. Budget range. Yes, really. See below.
  8. What you are not asking for, which prevents helpful over-scoping.

Describe workflows as steps, not features

“A dashboard for managers” is a feature request and tells a supplier almost nothing. “A manager checks on Monday morning which jobs are behind schedule and reassigns them” describes a workflow, and any competent supplier can price that.

Write the three most common workflows as numbered steps, from the user's first action to the outcome. A brief containing three good workflow descriptions will get better quotes than one containing thirty bullet-pointed features.

Say your budget

The common fear is that stating a budget means paying all of it. In practice, withholding it produces proposals aimed at the wrong scale entirely and wastes everyone's time.

A range works well: “we expect this to be £20,000–£40,000 and we would like to understand what each end buys.” That gets you comparable proposals scoped to a scale you can actually approve.

Include the awkward details

  • The legacy system nobody wants to touch but which must keep working
  • The approval process, especially if a committee is involved
  • The data that is in a poor state — suppliers will find out anyway
  • The previous attempt that failed, and what happened
  • The internal person whose support you will need and may not have

Disclosing these gets you a realistic price. Hiding them gets you an optimistic price followed by a change request, which is worse for both sides.

What to ask for in the response

Ask every supplier for the same structure: understanding of the problem, proposed approach, price broken into phases, timeline with milestones, assumptions, exclusions, and who will do the work.

The assumptions section is the most revealing part of any proposal. A supplier who lists ten specific assumptions has thought about your project; one with none has not read the brief carefully.

FAQ

Frequently asked questions

The questions readers ask us after this guide.

Still have a question?

Ask us directly — a senior engineer will get back to you.

Ask about your project

How long should a brief be?

Two to six pages for most projects. Longer than that and it is usually specifying a solution rather than a problem, which constrains suppliers from proposing something better.

Should we send it to many suppliers?

Three to five is plenty. More than that and you cannot evaluate properly, and good suppliers withdraw when they learn they are one of ten.

Do we need a technical person to write it?

No. A brief written in business language by someone who understands the process is more useful than a technical specification written by someone who does not understand the work. Suppliers can ask the technical questions.

What if we do not know exactly what we want?

Say so, and ask for a paid discovery phase — typically one to three weeks — that produces a specification and a fixed price. That is a legitimate and often sensible way to start.

Keep reading

More on Hiring & Budgets

Start here

Want your brief reviewed before you send it?

We will read it and tell you which sections are ambiguous enough to cause quote variance. No obligation, and no charge.

  1. You tell us what you needTwo minutes on the form, or a message on WhatsApp.
  2. A senior engineer reviews itAnd comes back with questions, a realistic range and an honest view on fit.
  3. Free 30-minute scoping callWe talk through scope, options and a realistic estimate — with no obligation.
Free estimateNo obligation

Talk to someone who builds this

Send a short brief and we will come back with an honest view and a realistic range.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →