A software brief is one page that says what is going wrong, who is affected, what should be different afterwards and what you can spend. Describe the problem, not the software. Give the same page to every developer you approach, so that their quotes can be compared. Eight short headings are enough: the organisation, the problem, the people, a day in the work, what must be recorded, what must come out, the limits, and how you will know it worked.
The eight headings
- Who we are. Two sentences. What you do, how many people, how many sites.
- The problem. What goes wrong today, how often, and what it costs you in money, time or customers.
- The people. Who would use it, how many of each, and what phones or computers they have.
- A day in the work. Follow one job, order or record from start to finish, as it happens now. This is the most useful part. Write it as a story.
- What must be recorded. The details you write down today. Attach the form or the sheet.
- What must come out. The lists, totals and reports you need, and who reads them.
- The limits. Budget, date, network conditions, anything it must connect to.
- How we will know it worked. One or two things you could measure in three months.
A worked example
This is an invented example for a hardware wholesaler, to show the level of detail.
| Heading | What they wrote |
|---|---|
| Who we are | A hardware wholesaler with one shop and one store room. Nine staff. |
| The problem | Stock is counted on paper once a month. We run out of fast items about twice a week and find out when a customer asks. Last count, the book and the shelf differed on 60 lines. |
| The people | Two store-room staff, four at the counter, one buyer, the owner. All have Android phones. One computer at the counter. |
| A day in the work | A delivery arrives. The store-room staff check it against the invoice and shelve it. The invoice goes to the office and is entered in a spreadsheet, sometimes days later. Counter staff take goods and write a slip. Slips are added up at the end of the day. |
| What must be recorded | Item, quantity in, quantity out, date, who. Breakages. Our item list is attached: about 800 lines. |
| What must come out | Each morning: items below their reorder level. Each month: stock value, and what moved fastest and slowest. |
| The limits | About N$20,000. Before the December season. The store room has weak signal. |
| How we will know | Running out of a fast item less than once a month. A count that differs on fewer than ten lines. |
Put through the estimator, that brief is a stock system with offline working, and the range shows whether N$20,000 covers a first version.
What to leave out
- The solution. “We need an app with a blue dashboard” closes off cheaper answers. Say what must happen, and let developers propose how.
- Every feature you can imagine. A long wish list raises every quote. Keep a separate list called “later”.
- Technical words you are not sure of. Plain words are safer than a term used slightly wrongly.
How to use it
- Send the same page to two or three developers.
- Ask each for a written list of what their first version does, the price, the time and the monthly costs.
- Compare the lists before you compare the prices.
- Ask each one what they would leave out to halve the price. The answers tell you who understood the problem.
Send it to us
A brief like this is all we need to write a free one-page scope. Send it by WhatsApp or email from the contact page.