Software5 min readBy Ahmed AkramPublished
How do you write a software brief that agencies can quote accurately?
Quotes for the same project can differ widely, and it's usually not because one agency is greedy. Each one filled the gaps in your brief with a different guess. A better brief gets you quotes you can compare, and a project that starts on solid ground.
Short answer
A good software brief says what problem you have, who uses the software, what must work on day one and what can wait, which systems and data it connects to, your budget range, the real reason for the deadline, and how you will decide it is done. It does not need to specify screens or technology. It needs to remove guesses.
Start with the problem, not the solution
Describe what is going wrong today and what it costs you. "Orders take three people two days to process, and mistakes reach customers" is a brief. "We need an app with a dashboard" is a solution someone has already chosen for you, and it might be the wrong one.
A good agency will challenge the solution if you give them the problem. If you hand over only the solution, they'll price exactly that, and you'll find out later whether it was the right thing.
Can you quote for our project?
We need a mobile app like Uber, but for our cleaning business. It should be modern and easy to use. How much?
The agency has to guess the scope, so it will either pad the price or leave things out.
Customers book cleaners by phone and some bookings fall through. We want customers to book and pay online, and our 12 cleaners to see their day on their phone. Budget range and launch date are below.
The problem, the users and the limits are visible, so the quote can be specific.
What the brief should cover
You don't need a long document. Two or three pages that answer these questions will do better than thirty pages of detail. Where you don't know an answer, write "not sure". That's far more useful than a confident guess, because the agency can then ask or propose a discovery phase.
Be specific about who the users are. "Customers" isn't enough. Say how many, how technical they are, and which devices they use. A tool for twelve office staff is a different project from one for twelve thousand shoppers.
Problem
What is wrong today, who feels it, and what it costs.
Users
Who will use it, how many, and on which devices.
Scope
What must work on day one, and what can wait.
Systems and data
What it connects to, and what data already exists.
Budget and date
A range, a deadline, and the reason behind it.
Must-have, nice-to-have, existing systems and data
Split your wish list into two columns. Must-haves are what you could not launch without. Everything else is nice-to-have, and you can ask for it to be priced separately. This one change makes quotes comparable and gives you something to cut if the budget is tight.
Then list your existing systems: accounting software, ERP, spreadsheets, a website, a payment provider. Integrations cause more surprises than any other part of a project. Also say where your data lives and how clean it is. Moving ten years of messy customer records is real work, and an agency can't price it if it doesn't know it exists.
Budget, deadline and what "done" means
Share a budget range. Some people hold it back, afraid the agency will spend all of it. In practice it does the opposite: it lets the agency tell you what is possible, and say honestly when the budget and the wishes don't match. Without it you get quotes for projects of very different sizes.
Give the real reason for the deadline too. A trade show on a fixed date is a hard limit. "Sometime in spring" is flexible, and the agency may be able to offer a smaller first version sooner. Finally, write down how you will know it is finished: which tasks a user can complete, how it behaves with real data, and who signs it off.
Reads like a good brief
- States the problem and what it costs today
- Names the users and how many there are
- Separates must-haves from nice-to-haves
- Lists existing systems and where the data lives
- Gives a budget range and the reason for the deadline
Reads like a vague brief
- Describes screens and features, not the problem
- Says "modern" and "user friendly" without detail
- Treats every feature as equally important
- Forgets about integrations and old data
- Has no budget and no definition of done
Questions people also ask
How long should a software brief be?
Two to four pages is usually enough. Clear answers to the basic questions matter more than length. If you're unsure about parts, say so and let the agency suggest a short discovery phase.
Should I tell agencies my budget?
Yes, give a range. It helps the agency propose something that fits, and it makes the quotes comparable. A good agency will tell you if the range and the scope don't match, rather than quietly taking the top of it.
Do I need to choose the technology in the brief?
No, unless you have a real constraint, such as a system you must integrate with or a platform your IT team supports. Describe the problem and the limits, and let the agency recommend the technology and explain why.
Related service
Have a rough idea but no brief yet? We'll help you shape one before you ask for quotes.
Talk to usMore articles
- SoftwareChoosing a software agencyThe green flags, the red flags, and the questions worth asking before you sign anything.Read the article
- SoftwareAgency or in-house team?How an agency, a freelancer and an in-house team differ on cost, speed and knowledge, and how to hand over cleanly.Read the article
- BlockchainAI and blockchain by 2030Where AI and blockchain meet in real business use over the next five years, and which loud claims are safe to ignore.Read the article
