A good software brief explains the problem, who'll use the software, the steps they need to go through, the data involved, the tools it has to connect to, and how you'll judge whether it worked. You don't need to describe screens or the technology. Developers can design those. What they can't guess is how your business actually works.
Use the sections below as a template. A page or two of honest answers is better than twenty pages of feature lists.
1. The problem, in one paragraph
What's going wrong today, and what does it cost you? 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 one 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, like admin, sales, delivery and management
- Clients, and whether each client has one login or several
- Partners, suppliers or coaches
For each one, write a line on what they need to do. How many types of user you have is one of the biggest things that drives the cost, so it's worth getting right.
3. The main steps people go through
Write out the three to five most important processes, step by step, in plain words. For example:
- A new client gets 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 gets a notification and the project is created.
Mark which steps happen today and which ones are new.
4. The information involved
What records does the software hold? Clients, projects, documents, payments, messages, bookings. Where does that information live right now, and does any of it need to move across?
If there's existing data to move, say how much and where it's coming from. Messy data takes time to clean, and it's better to know that up front.
5. Connections to other tools
List the tools it has to work with, like your CRM, accounts software, calendar, payments and email. For each one, say which way the data goes. Reading from a system is simpler than keeping two systems matching in both directions.
6. Must-haves and nice-to-haves
Split every feature into two lists. The must-haves are what the first version can't launch without. Everything else waits for version two, once real users have shown you what matters. This one step does more to keep the budget under control than anything else in the brief.
7. Limits and requirements
- Budget range. Sharing it means a developer can suggest the right size of first version instead of guessing.
- Timing. Any real deadline, and why it's there.
- Access and privacy. Who must never see what, and any industry rules you have to follow.
- 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, like time to onboard a client, hours spent on a task, or enquiries that get to a booked call. Without these, nobody can tell whether the project worked.
Questions a good developer should ask you
If a quote comes back and none of these were asked, be careful:
- What happens when something goes wrong at this step?
- Who approves this step?
- What should each type of user not be able to see?
- What does the business do today when this 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, write down 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's ready, bring it to a discovery call. We turn it into a written scope and price before anything gets built, and we'll tell you if part of it is better solved with a tool you've already got.
