A good software brief describes the problem, who will use the software, the journeys they need to complete, the data involved, the tools it must connect to, and how you will judge whether it worked. It does not need to describe screens or technology. Developers can design those. What they cannot guess is how your business works.
Use the sections below as a template. A page or two of honest answers beats twenty pages of feature lists.
1. The problem, in one paragraph
What is going wrong today, and what does it cost? Be specific.
Weak: "We need a better system for managing clients."
Strong: "Client onboarding takes two weeks because we chase documents by email. We lose about one new client a month who gives up before starting, and two people spend most of Monday chasing."
The strong version tells a developer what to fix and how to measure it.
2. Who will use it
List every type of user and how many of each:
- Staff roles, such as admin, sales, delivery and management
- Clients, and whether each client has one login or several
- Partners, suppliers or coaches
For each, one line on what they need to do. The number of user types is one of the biggest drivers of cost, so it is worth getting right.
3. The main journeys
Write out the three to five most important journeys, step by step, in plain language. For example:
- A new client receives a link and creates their login.
- They fill in their details and upload three documents.
- They sign the agreement.
- They pay the first invoice.
- Our team is notified and the project is created.
Mark which steps happen today and which are new.
4. The information involved
What records does the software hold? Clients, projects, documents, payments, messages, bookings. Where does that information live now, and does any of it need to move across?
If there is existing data to migrate, say how much and where from. Messy data takes time to clean, and it is better to know up front.
5. Connections to other tools
List the tools it must work with: your CRM, accounts software, calendar, payments, email. For each, say which way data flows. Reading from a system is simpler than keeping two systems in sync in both directions.
6. Must-haves and nice-to-haves
Split every feature into two lists. The must-haves are what the first version cannot launch without. Everything else waits for version two, once real users have shown you what matters. This single step does more to control budget than anything else in the brief.
7. Limits and requirements
- Budget range. Sharing it helps a developer propose the right size of first version rather than guess.
- Timing. Any real deadline, and why.
- Access and privacy. Who must never see what, and any industry rules that apply.
- Ownership. Whether you need to own the code and data. You should.
8. How you will judge success
Pick two or three numbers you can measure before and after: time to onboard a client, hours spent on a task, enquiries that reach a booked call. Without these, nobody can tell whether the project worked.
Questions a good developer should ask you
If a quote comes back without these questions being asked, be careful:
- What happens when something goes wrong in this journey?
- Who approves this step?
- What should each type of user not be able to see?
- What does the business do today when this situation comes up?
- Which of these features would you drop if the budget were half?
A shortcut
If you already run the process on a spreadsheet, list what each tab and column does. That covers most of sections 3 and 4. Our guide to spreadsheets that should be software explains how to spot which ones are worth replacing.
When your brief is ready, bring it to a discovery call. We turn it into a written scope and price before anything is built, and we will tell you if part of it is better solved with a tool you already have.
