✦ Sales assets
How to write a software brief your developer can quote from
How to write a software brief comes down to one test: could two different suppliers read it and quote roughly the same price? If not, it's a wish list, not a brief. Here's the section-by-section outline that gets you a comparable, accurate quote.
Haystak · 11 August 2026 · Updated 11 August 2026 · 8 min read
How to write a software brief is a question worth answering properly, because a vague brief produces vague quotes that fall apart the moment the build starts. You don't need to be technical to write a good one - you need to be specific about the problem and honest about what you don't yet know.
What follows is an outline, not a form to download. Work through it in a document of your own; the structure matters more than the software you write it in.
1. The problem, in plain language
Start with what's broken today, not what you want built. "Our team re-keys the same order into two systems and it goes wrong twice a week" tells a supplier more than "we need an integration." Include who is affected and roughly how often the problem occurs.
2. The people who will use it
- List every distinct role that will touch the system - not job titles, but what each role needs to do.
- Note roughly how many people are in each role, and whether that number is expected to grow.
- Flag any external users (customers, suppliers) separately from internal staff - external access usually adds security and support requirements.
3. What the system must do
Write this as a numbered list of things the system does, from the user's point of view, not features. "A sales admin can create a quote and send it to a customer by email" is a requirement. "Quote generation module" is not - a supplier can't quote something they have to guess the meaning of.
Separate the list into must-have and would-like. This is the single biggest lever on cost, and it forces you to decide what actually matters before a supplier prices in everything you mentioned.
4. What it needs to connect to
| System | What data moves | Direction | How you connect today (if at all) |
|---|---|---|---|
| e.g. accounting package | Invoice totals | One-way, system to accounts | Manual export/import |
| e.g. CRM | Customer contact details | Two-way | None - separate systems today |
Every row here is a genuine cost driver - see what does custom software cost for why integrations move price more than almost anything else.
5. Data: what exists today, and how clean it is
If you're migrating data from a spreadsheet, an old system, or someone's memory, say so and be honest about its state. "Customer records in a spreadsheet, roughly 4,000 rows, duplicates likely" lets a supplier scope cleanup properly instead of discovering it mid-project.
6. Constraints
- Timeline - a real deadline (a contract renewal, a regulatory date) is different from "as soon as possible". State which you have.
- Compliance - any sector-specific record-keeping, data protection or audit requirement the system must meet.
- Existing technology - anything the new system must work alongside, run on, or avoid breaking.
- Support expectations - office hours is very different to needing guaranteed uptime out of hours.
7. How you'll judge the quotes
State this explicitly, even briefly: is price the deciding factor, or references, technical approach, and post-launch support? Suppliers price differently when they know cost isn't the only variable, and you'll get more honest quotes as a result.
Compare what you get back using the same yardstick - see fixed price vs day rate for the commercial models you'll likely be offered, and who owns the code for the contract terms worth checking before you sign anything.
A brief is not a specification
A good brief gets you a comparable, reasonably accurate quote from more than one supplier. It is not the detailed specification the winning supplier will produce during discovery, and it shouldn't try to be - that level of detail (screens, data model, edge cases) is properly a paid piece of work once you've chosen who to work with.
If you'd rather talk it through than write it alone, that's exactly what a scoping call is for - see how we work or get in touch and we'll help you turn a rough problem into something quotable.
For a formal reference on what a complete specification eventually needs to cover, ISO/IEC/IEEE 29148 is the standard for requirements engineering, though it's far more detail than any brief needs at this stage.
✦ Where this fits
More on this from us: how we work.