How to write a software brief that gets you an accurate quote

The quality of the quotes you receive depends almost entirely on the quality of the brief you send. A vague brief gets vague quotes that cannot be compared and a project that changes shape halfway through. A clear one gets fixed prices for the same thing from everyone. It does not need to be long. Here is what to include.

1. The problem

One or two paragraphs on what is going wrong today and what it costs you. "Our sales team retype orders from email into a spreadsheet and then into Sage. It takes around ten hours a week and about one order in fifty has an error that reaches the customer." That paragraph tells a developer more than any feature list.

2. What you want to be different

What will be true when the project succeeds? "Orders entered once. No retyping. Errors visible before dispatch. Management can see order status without asking." This is how you will judge the result, so write it down now.

3. The users

Who will use the software, and what does each type of person need to do? "Sales (4 people): create and edit orders. Warehouse (3): see pick lists, confirm dispatch. Accounts (1): see invoices, mark as paid. Customers (200): log in, see their orders." Grouping features by user is the easiest way to be complete.

4. What it must do

A list of features under each user type, marked must-have or nice-to-have. Be concrete. "Search orders by customer, date or product" is better than "good search". Where something is unusual, add a sentence of context.

Include real examples: three typical scenarios and three awkward ones, walked through step by step. The awkward ones are where the real requirements hide.

5. Systems it must connect to

List every system the software must read from or write to: accounts package, CRM, online store, courier, payment gateway, email. Say what should flow in each direction. Integration is often a large part of the work and is easy to forget. See what is system integration.

6. Existing data

What data exists today, where, in what state, and whether it needs migrating. "Around 2,000 customers in a spreadsheet, some duplicated. 15,000 historical orders in Sage that we would like to keep read-only."

7. Constraints

Anything the developer needs to respect: must work on tablets in the warehouse, must be usable offline on site, must comply with a client's security requirements, must be live before a specific date, must not exceed a budget range. Say your budget range. Developers can then tell you what is achievable within it rather than guessing.

8. What is out of scope

Just as useful as what is in. "Not in scope: replacing Sage, a mobile app, anything for suppliers."

9. How you will work together

Who is the decision maker on your side, how much time they have, how you prefer to communicate, and how quickly you can review and sign things off.

10. What you want from the quote

Fixed price for the defined scope, what is included (design, testing, training, data migration, warranty, support), timeline, and how changes are handled. Asking everyone for the same structure is how you compare fairly.

Keep it short

One to three pages is enough. Attach screenshots of current tools, sample documents and the spreadsheets you are trying to replace. That combination gets you accurate quotes from people who understand the job.

What happens next

Send the brief to two or three developers. Expect each to come back with questions; that is a good sign. Our guide to choosing a software development company covers what to ask them in return. And if you want to talk it through before writing anything, our free discovery call works from a conversation just as well as a document. Request a quote.

Frequently asked questions