The quality of a software project is often decided before any code is written. Send five companies a one-paragraph idea and you will get five quotes that differ by a factor of three, because each one has imagined a different product. Send them a clear brief and the quotes become comparable, the questions become better, and the project that follows has far fewer surprises.
A good brief does not need to be long or technical. Two to five pages is usually enough. Here is what to put in it.
1. The problem, in business terms
Start with why the software is needed, not with features. What is slow, expensive, error-prone or impossible today? Who feels it? What does it cost? “Our sales team re-types every order from email into the ERP, which takes two people a full day each week and causes about one wrong delivery a week” tells a developer far more than “we need an order portal”.
2. The users
List the kinds of people who will use the software, and what each one needs to get done. Customers, staff, managers, partners, administrators. For each, note how many there are, how often they will use it, and on what device. A field technician on a phone in a basement and an accountant on two large screens need very different things.
3. What the first version must do
This is the most important section, and the hardest. Write the list of things the software must do, then split it honestly into three groups:
- Must have for the first release: without it, nobody would use the software.
- Should have soon after: valuable, but launch could happen without it.
- Could have later: ideas worth keeping, not worth delaying the launch for.
Most first versions are too big. A small first release that real users can try teaches you more than a large one that takes a year.
4. What it has to work with
List the systems the software must connect to: your ERP or accounting system, CRM, payment provider, email, single sign-on, existing databases or apps. For each one, note whether it has an API and who can give access to it. Integrations are where most estimates go wrong, so mention them early.
5. Data
What information will the software hold, roughly how much, and where does it come from today? Is there existing data to move across, for example customer records in spreadsheets? Is any of it personal or sensitive, such as health or financial data? This affects both the design and the legal requirements.
6. Constraints
- Deadline, and why it is fixed if it is: a trade show, a contract, the end of a licence.
- Budget, at least a range. Sharing a range does not weaken your position; it lets a good partner suggest what fits in it.
- Technology you must use, or must avoid, and why.
- Rules you have to follow: privacy law, industry regulation, accessibility, your own security policies.
7. What success looks like
How will you know, six months after launch, that the project worked? Pick two or three measures: time saved per week, fewer errors, more orders, faster response to customers. These keep everyone focused on outcomes rather than on a feature list.
8. Examples
Screenshots of software you like, or dislike, and a sentence on why. Rough sketches on paper are fine. Examples remove a surprising amount of misunderstanding.
9. Who decides
Name the person on your side who can answer questions and approve work, and how much time they can give each week. Projects slow down most when nobody on the client side can make decisions.
What not to worry about
You do not need to choose the technology, design the database or write technical specifications. A good development partner will do that with you, and will ask the questions your brief does not answer. If you are unsure about parts of it, say so. “We don’t know yet” is useful information.
Then what?
Send the same brief to every company you are considering, so the answers are comparable. Pay attention to the questions they ask back: thoughtful questions are a better sign than a fast quote. For larger or less certain projects, a short product discovery phase turns the brief into a detailed scope, a prototype and a reliable estimate before the main build begins.
We build custom software and first versions of new products. Send us your brief, however rough, and we will tell you honestly what we would build first and what it would take. You can book a free consultation to talk it through.