How to Brief a Software Project: The Document That Decides Your Quote

Quick answer

The quality of your brief sets the price of your software twice: vague briefs get padded quotes (developers price uncertainty as risk), and wrong briefs get accurate quotes for the wrong thing. The good news is that a strong brief isn’t technical — it’s a clear description of the problem, the people who have it, the workflow as it really happens, and what “working” would mean. The developer’s job is turning that into architecture; your job is making sure they’re solving the right problem. One page done well beats a ten-page feature list every time.

What belongs in the brief (one page, six sections)

1. The problem in operational terms. Not “we need a booking system” but “we take 40 bookings a week by phone and WhatsApp; double-bookings happen weekly; two staff spend Friday afternoons untangling the diary.” The second version lets a developer propose the right-sized solution — sometimes smaller than you imagined.
2. Who touches it. Every user type and their situation: office staff on desktops, fitters on phones in poor signal, customers of all ages. This single section drives more design decisions than any feature list.
3. The workflow as it actually happens. Walk one real job end to end, including the workarounds and exceptions (“unless it’s a trade customer, then we invoice monthly”). Exceptions are where software projects blow up; surfacing them in the brief is free, discovering them in month three isn’t.
4. What it must connect to. Accounting package, calendar, payment provider, existing website, that supplier portal. Integrations are priced work — naming them upfront keeps the quote honest (see API integration costs).
5. What “working” means. Two or three measurable outcomes: “no double bookings”, “invoice out same day as job completion”, “owner sees the week’s schedule without phoning anyone”. These become the acceptance test.
6. Budget range and timeline honesty. Naming a range (£8–15k, need it before September) isn’t negotiating against yourself — it lets suppliers propose the best solution inside your constraints instead of the perfect one outside them. The market rates to calibrate against: custom web app costs.

What to leave out

• Solution mandates you can’t defend. “Must be built in React with a NoSQL database” from a non-technical buyer forces developers to either argue or comply against judgement. State constraints that are real (must run on our Microsoft accounts; must be maintainable by UK suppliers) and leave stack choices to the people you’re paying for that judgement — the trade-offs are explained in custom vs off-the-shelf and web app vs mobile app vs website.
• The everything-list. Fifty features at equal priority is not a brief, it’s a wish. Split must-have (the problem doesn’t get solved without it) from nice-to-have (v2 candidates) — this split alone typically cuts first quotes by 30–50% by revealing the actual MVP.
• Invented volumes. “Must scale to 100,000 users” for a 12-person firm adds architecture cost for a future that may never come. Give real numbers: users today, growth expected, records per month.

Reading the responses

The brief is also a supplier filter. Good signs: they ask questions that show they read it, challenge something (a supplier who pushes back on scope before the contract will push back on scope creep after it), and propose phases rather than one big bang. Warning signs: a quote back within hours for a custom build, agreement with everything, and estimates given as single numbers rather than ranges with assumptions. Pricing custom work from a one-page brief is estimation, not measurement — honest suppliers say so. The same client-side discipline applies as in briefing a designer: the brief starts the collaboration, it doesn’t end it. When you’re ready, this is the shape of conversation our custom business software projects start from.

Running a three-supplier tender without wasting anyone’s time

A brief is only useful if it goes somewhere. The efficient shape for a small business is three suppliers, the same document, the same deadline and the same questions — any more and you cannot compare properly, any fewer and you have no market reference.

1. Send the brief to three, not eight. Tell each of them how many others are quoting. Serious suppliers price differently when they know they are one of nine, and usually by declining.
2. Allow two weeks. A considered proposal for a £15,000 build takes a day of someone’s time. Demanding it by Friday selects for whoever is least busy.
3. Offer one call each. Half an hour of questions, and circulate the answers to all three so nobody is quoting on better information than the others.
4. Ask for the same structure back. Approach, phases with prices, assumptions, exclusions, timeline, team, and what happens after launch. Free-form proposals cannot be compared side by side.
5. Score before you read the prices. Rank the proposals on understanding and approach first, then look at cost. Doing it the other way round means the cheapest quote sets the frame for everything else.

Comparing quotes that are not comparable

Three quotes at £9,000, £16,000 and £34,000 for the same brief is normal, and it rarely means two suppliers are wrong. It usually means they have read different scopes into the same words. Before concluding anything, normalise them against the same checklist.

Once you have added the missing lines back, the gap between the three usually halves. The remaining difference is genuine — capacity, seniority and risk appetite — and that is a real choice rather than an error, explored properly in software agency versus freelance developer.

Sizing the first phase deliberately

The strongest thing a brief can do is name what version one deliberately does not include. Write two lists: the workflow that must work end to end on day one, and everything the business would like eventually. Then commit to building only the first, with the second visible so no supplier designs an architecture that makes it impossible.

A worked example. A hire company briefs an asset-tracking system. The everything version — customer portal, online payments, mobile app for drivers, damage photos, automated overdue chasing, accounting sync — quotes at around £40,000. The phase-one version, which is bookings, availability and a printable job sheet, quotes at £11,000 to £14,000, runs the business better than the spreadsheet within two months, and produces a list of genuine requirements for phase two written by people who have used the thing. The second version is nearly always different from what was imagined, which is the argument for staging in the first place and the discipline described in scoping a first version that proves something.

Commercial terms to settle before work starts

• Intellectual property. State that ownership of the bespoke code transfers to you on final payment. Reused libraries and the supplier’s own frameworks will be licensed rather than assigned — that is normal, but you need it in writing.
• Source code access. Ask for the repository to be hosted in your organisation’s account from day one. A business that cannot reach its own code has no second supplier option.
• Payment structure. Milestone payments tied to demonstrable deliverables, not calendar dates. A deposit of 25–40% is standard; paying the majority up front is not.
• Change control. Agree how a change is quoted and approved before the first one arrives, because the first one always arrives.
• Data and hosting. Who holds credentials, where the data lives, and what happens to it if the relationship ends. If you handle personal data, this is also a compliance question rather than only a commercial one, as set out in GDPR-compliant software.
• Warranty and support. A 30–90 day defect-fix period at no charge, then a stated ongoing arrangement. Budget realistically for the ongoing part, because support and hosting are what surprise owners in year two.

Briefing mistakes that survive into the build

Describing the current system instead of the current problem produces a more expensive copy of software you already dislike. Writing the brief alone, without the people who do the work daily, guarantees the exceptions surface in testing rather than in scoping. Hiding the budget produces proposals that miss in both directions and wastes everyone’s fortnight. Approving screens without walking a real job through them means the acceptance test happens after go-live, on live customers.

The most expensive of all is treating the brief as a document rather than a decision record. Every awkward question you avoid — what happens to part-completed jobs, who can delete a record, what the system does when the integration is down — is a decision someone will make anyway, usually a developer at speed and without context. Write the awkward answers in, and the quote you receive is a price for the thing you actually need. If the honest conclusion is that no bespoke build is required and a configured product would do, that is the brief working correctly — plenty of projects that start as “we need a system” turn out to be an ecommerce platform build with two integrations behind it, quoted at a third of the price and shipped in a quarter of the time.

Sources & Further Reading

• Agile Delivery Guidance — GOV.UK Service Manual
• Chartered Institute for IT — BCS
• Developer Survey — Stack Overflow