What should a custom software brief contain?

The process as it runs today, the users and their permissions, data volumes, systems to integrate with, one sentence defining done, and a list of what is not in the first version.

Should custom software be bought at a fixed price?

Only on a tightly bounded scope. On a vague brief a fixed price is either padded with contingency or leads to arguments over every change.

How long does writing a brief take?

Two to five days of work if it is written with the people who actually do the job. Without them it takes longer and the result is less accurate.

How to brief a custom software project

25 February 20256 min read

Short answer

A good brief does not describe a solution. It describes the work the system is meant to remove: who does it today, how often, what they need to see while doing it, and what happens when something goes wrong. A supplier given that can quote a comparable price. A supplier given a feature list can only guess.

01What belongs in it

Six things, a few paragraphs each. Nobody reads twenty pages and they do not help.

01The process as it runs today — including what happens outside the system, in e-mail and spreadsheets.
02Who the users are and what each needs to see and change.
03Volumes: records per month, number of users, any peaks.
04The systems it has to talk to, and whether they have an API.
05What done means: one sentence you could use to say it works.
06What is not in the first version. This is the most valuable paragraph in the document.

02Fixed price and its condition

A fixed price is fine on a tightly bounded scope. If the brief is vague and a supplier quotes a fixed price anyway, they have either padded it for the uncertainty or will argue about every change. Usually both.

Healthier is a fixed price on a first, well-bounded piece and an estimate for the rest. After that piece both sides know how they work together, and the estimate becomes far more accurate.

03What to ask a supplier

The answers to these four say more than any reference list.

01Where will the data live and who has access to it?
02What happens when the relationship ends — do we get the code, the data and the accounts?
03Who will actually build it, and is that the person I am talking to now?
04How will we handle changes mid-project when we discover something should work differently?

04The most common mistake

Describing the software you imagine instead of the problem it should solve. A brief saying “we want a dashboard with charts” produces a dashboard with charts that nobody opens after a month.

“We want to see which jobs are running late so we can call before the customer does” can be solved better than you expected. The first sentence does not allow that.

Frequently asked

What should a custom software brief contain?: The process as it runs today, the users and their permissions, data volumes, systems to integrate with, one sentence defining done, and a list of what is not in the first version.
Should custom software be bought at a fixed price?: Only on a tightly bounded scope. On a vague brief a fixed price is either padded with contingency or leads to arguments over every change.
How long does writing a brief take?: Two to five days of work if it is written with the people who actually do the job. Without them it takes longer and the result is less accurate.