“The moment a developer writes a line of code without a clear brief is the moment the project starts accumulating hidden cost. Every assumption they make will need to be corrected.”
Why the brief mattersA software brief is a document that explains what you want built, who will use it, and what a successful outcome looks like. It is not a technical specification. It does not require knowledge of code. It requires clarity about your business, your users, and your goals — which you have, and a developer writing code without it does not.
A good brief takes three to five hours to write. The quotes you receive from it will be more accurate. The work delivered against it will be closer to what you intended. The disputes during and after the project will be fewer. This guide walks you through every section.
Section 1: The Problem You Are Solving
Start with the problem, not the solution. Describe the specific pain that the software will address, for whom, and how they currently deal with it. The goal is to give the development team enough context to make good decisions when the brief is ambiguous — which it will be in places, regardless of how carefully you write it.
Example of a weak problem statement: 'We need a booking system for our business.' Example of a strong problem statement: 'Our physiotherapy clinic currently manages 40 appointments per day using a paper diary and phone calls. Double bookings happen three to four times per week. Patients frequently call to change appointments with less than 24 hours notice, which leaves gaps. We need patients to book, reschedule, and cancel their own appointments online, with automatic reminders 24 hours before each session.'
Section 2: The Users
Describe each type of person who will use the software and what they need to be able to do. Be specific. A 'user' is not a useful description. A 'gym member who wants to book a class from their phone while they are on the bus to work' is a useful description because it tells the developer what devices to prioritise, what speed constraints matter, and what the context of use is.
Section 3: What the Software Must Do (MVP Scope)
List the specific features in your MVP — the minimum set of functionality required to test whether the software solves the problem. Be explicit about what is in scope and what is deliberately out of scope for this version. 'Out of scope for now' features are not lost — they inform the architecture without requiring immediate implementation.
Write each feature as a user action: 'A patient can view available appointment slots for the next two weeks and book a time.' Not: 'A booking calendar.' The former tells the developer what the feature does and gives them acceptance criteria. The latter leaves the implementation entirely to interpretation.
Section 4: What Success Looks Like
Describe what a successful outcome looks like at 30, 90, and 180 days after launch. Use specific, measurable terms: 'fewer than 3 double-booking incidents per week' rather than 'reduced double bookings.' These success criteria also serve as acceptance criteria for the project — a shared definition of done that both sides can evaluate against.
Section 5: Constraints
Document everything that constrains the design or development options. This includes existing systems that the new software must connect to (include any documentation you have on their APIs), regulatory requirements (data privacy laws, healthcare compliance, payment regulations), device or browser requirements, and performance expectations at your current and target user volume.
Section 6: Timeline and Budget
Be honest about your timeline and budget range. A development team that knows you have a hard launch date for a product event will make different decisions than one that believes the timeline is flexible. A team that knows your budget ceiling will design an MVP that fits within it rather than proposing a scope that does not.
You do not need to share a precise budget figure if you are uncomfortable doing so. Sharing a range — 'we have a budget of $20,000 to $35,000 for the MVP' — is sufficient to allow the development team to scope appropriately.
