A good software brief describes the problem, not the technology. In a few pages it should say what is going wrong today, who will use the new system, which features are must-haves and which are optional, what data it will hold (including any personal information), which systems it must connect to, what "done" looks like, and what you expect to receive in writing. Without that, two quotes for "a simple job management app" can describe two very different systems.
What a brief is for, and what it is not
A brief is your side of the conversation before any scoping starts. It is not a technical specification, so you do not need to name a database or a host. The developer turns your brief into a written scope. When we scope a custom software project, that scope is a written list of what the system must do and a clear line around what is out of scope. The better your brief, the less of that line is guesswork.
A clear brief also shows early whether a subscription or a connection between your existing tools would do the job. Our guide on whether to build software or buy a subscription covers that decision, so this guide assumes you are ready to describe what you want built.
The nine sections of a software brief
Use this as a template. The example column follows one everyday business: a plumbing company with an office team and crews on the road, which wants to stop booking jobs on a whiteboard.
| Section | What to write | Example |
|---|---|---|
| The problem | What goes wrong today, in plain words, and what it costs you in time or errors | Jobs are booked on a whiteboard and texted to crews, so double bookings and lost job notes happen every week |
| The users | Each kind of person who will use it, and where they work | Office staff at a desk, plumbers on a phone in the van, the owner checking the week's jobs |
| Must-have features | What the first version cannot launch without | Book a job, assign it to a crew, crew marks it complete with photos |
| Optional features | What would be good later, clearly marked as later | Customer text reminders, a parts stock list |
| The data | What records it will hold and where they live now | Customer names and addresses, job history in a spreadsheet, invoices in the accounting system |
| Personal information | Which records identify people, and who may see them | Customer phone numbers and home addresses, visible to the office and the assigned crew only |
| Systems to connect | Every system it must talk to, and what passes between them | Completed jobs become draft invoices in the accounting software |
| What "done" means | How you will test it and decide it is ready | A full week of real jobs run through it alongside the whiteboard, with no lost bookings |
| What to get in writing | Ownership, handover, support and how changes are handled | Code and data owned by the business, changes quoted before work starts |
Must-have and optional features: draw the line early
business.gov.au gives the same advice for any digital tool for business: list your must-have and optional features before you look at options, and choose based on what you need now, not what you might use later. It also suggests working out the total cost of ownership, which is the upfront cost plus the running costs over the tool's life span.
For custom software, that line decides the size of the first version. Write each must-have as something a person does ("a plumber marks a job complete and adds photos"), and ask of each one: could we launch without it? Starting with the smallest version that removes the main problem, releasing it and quoting later stages once staff have used it is often the sensible way to build.
Features are only part of a quote: the kinds of user and screens, the connections, how much existing data has to move and the support you want afterwards all matter, as our guide to what drives the cost of a business app explains. Your brief should touch each of those.
The data, and the personal information in it
List the records the system will hold and where they live today, then mark which are personal information. business.gov.au describes personal information as anything that could identify a person, including a name, address, email, phone number, date of birth, bank details, photos and IP address.
Two privacy principles belong in the brief. First, collect only what you need: the OAIC says that under APP 3 you should only collect personal information that is reasonably necessary, and that over-collection can increase security risks. Second, plan privacy in from the start. The OAIC's guidance for start-ups describes privacy by design as building privacy management into technologies and business practices from the beginning, and warns that retrofitting it later can increase costs and cause delays.
Most small businesses with an annual turnover of $3 million or less are not covered by the Privacy Act, but some are regardless of turnover, such as health service providers. Ask the developer where the data will be stored, because APP 8 covers the steps a covered business must take before personal information is disclosed overseas. If you are unsure whether the Act applies to you, ask a lawyer or check with the OAIC. Our guide to data breach obligations for small business explains what follows if records are exposed.
Systems to connect: name every one
For each system, write its name, which direction information flows and which system holds the "true" version of a record. "Completed jobs become draft invoices in Xero, and customer details are edited only in the new system" is a line a developer can price. "Integrates with our accounts" is not.
Many common pairings already have a ready-made connector; custom work is for when one cannot handle your tax codes, pricing, locations or volume. If the system will hold hiring records, also name the platform your team uses for candidate checks, such as Talent Tabloid, a recruitment and candidate verification platform, so the connection is priced from the start. Our guide to business software integration shows where connections usually break.
What "done" means, and what to get in writing
State the purpose of the system in the brief. The ACCC says services, and any resulting products, must be fit for any stated purpose, and must be supplied within a reasonable time when no time frame is agreed. A written purpose and agreed dates give both sides something clear to check against; the ACCC's page on consumer rights for services sets out the rules.
Describe how you will test it: real users and records, on the devices your staff use. The Australian Signals Directorate says businesses that develop software, especially for websites, should use a quality assurance process that includes scanning for vulnerabilities.
Finally, ownership. IP Australia says IP created by a contractor belongs to the contractor unless the contract says otherwise, and that a written contract should be signed before work starts, defining who owns what is created and when ownership transfers. Our comparison of custom and off-the-shelf software goes deeper on ownership.
How to write your brief, step by step
- Write the problem in one paragraph: a normal week and where it goes wrong.
- List every kind of user and where they will be when they use it: desk, site, counter or road.
- Split features into must-have and optional, each written as something a person does.
- List the data and mark the personal information, with who should see each part.
- Name every system to connect, the direction of each flow and the source of truth.
- Define "done": the test you will run and how you will judge it ready.
- List what you want in writing: ownership of code and data, the handover, support after launch and how changes are quoted.
Common mistakes in software briefs
- Describing screens instead of problems. A sketched screen locks in one answer before anyone has looked at the question.
- Marking everything as a must-have. The first version gets bigger and dearer, and nothing is learned from real use until it is all built.
- Forgetting the data that already exists. Moving old records is one of the main cost drivers, so say how much there is and where it lives.
- Collecting personal information "just in case". Over-collection increases security risk, so leave out fields nobody needs.
- Leaving ownership to the end. Without a written agreement, IP a contractor creates is the contractor's.
- Relying on memory. business.gov.au says disputes often come from different expectations about results, and advises putting everything agreed into the written document.
Frequently asked questions
How long should a software brief be?
Long enough to cover the nine sections, which for most small business systems is a few pages. Plain sentences and clear lists of users and features help a developer more than technical detail.
Do I need technical knowledge to write a software brief?
No. A brief describes the problem, the people, the data and the outcome in business terms. Turning it into a technical scope, with screens, structure and hosting, is the developer's work during discovery and scoping.
What is the difference between a must-have and an optional feature?
A must-have is something the first version cannot launch without; an optional feature is useful but can wait. business.gov.au advises listing both before you look at options and choosing on what you need now.
Should the brief mention privacy if my business is small?
Yes. Some small businesses are covered by the Privacy Act whatever their turnover, and the OAIC recommends protecting personal information as best practice anyway. Planning privacy in from the start avoids costly redesigns later.
Who owns the software once it is built?
It depends on the contract. IP Australia says IP created by a contractor belongs to the contractor unless the contract says otherwise, so agree in writing, before work starts, who owns the code and when ownership transfers.
When your brief is ready, send it to us through our enquiry page. Every project starts with a discovery call, our free first consultation, and nothing starts until a fixed or staged quote is agreed in writing. If you are not yet sure what to build, our IT consulting work starts with an audit of what you already have, and our business systems and integrations team handles the connections.
Key takeaways
- A software brief describes the problem, the users and the outcome, not the technology.
- Split features into must-have and optional, and keep the first version small.
- List the data, mark the personal information and collect only what you need.
- Name every system to connect and which one holds the true record.
- Agree purpose, dates, ownership and change handling in writing before work starts.