How to write a technical brief that gets accurate quotes
A vague brief does not produce a cheap quote. It produces a low quote that grows later, or an honest supplier who declines. Either outcome wastes weeks.
Describe the job, not the technology
Start with what a person does today, step by step, and what should happen instead. "Sales team re-types orders from email into the ERP" is a brief. "We need an API-first microservice architecture" is a decision that belongs later, with the people who will maintain it.
Include volume: how many orders, users, records, and requests per day. Volume is what turns a feature list into an engineering estimate.
The eight sections worth writing
Problem and current process. Users and roles. Core flows, numbered. Data you already have and where it lives. Integrations with named systems. Constraints such as deadlines, compliance or budget bands. Success measures. Out of scope for this phase.
Out of scope is the section clients skip and later regret. It is the cheapest place to prevent scope arguments.
What to attach
Screenshots of the current tool, sample spreadsheets, screenshots of two products you like, and any brand assets. If a spreadsheet drives your operation, send the actual spreadsheet with the sensitive columns removed. It explains more than a page of prose.
Common questions
- How long should a project brief be?
- Two to four pages is usually enough for a clear project. Length is not the goal; the goal is that two developers reading it independently would describe the same system.
- Should the brief include a budget?
- A range helps more than an exact figure. It lets suppliers propose scope that fits rather than guessing and discovering the mismatch after the proposal stage.
Next step
If this question is live in your business right now, describe the situation and you will get a written view on the options, including whether you should build at all.
Discuss your projectRelated notes
All insightsCustom software or off-the-shelf: how to decide
A practical framework for choosing between configuring an existing product and commissioning custom software, based on where your process actually differs.
ReadStrategyRebuild or repair: an honest test for an ageing website
How to tell whether your existing website needs a migration or a targeted fix, using five checks that take an afternoon rather than a month.
ReadStrategyPlanning a technology budget that survives the year
How to split spend between build, maintenance and improvement so that the second year of a platform is funded before it starts.
Read