Why quotes vary so much
If you have ever sent the same software project brief to three agencies and received quotes ranging from £8,000 to £80,000, you have experienced the vague-brief problem firsthand. When developers cannot see the scope clearly, they either pad the estimate to cover uncertainty or strip out everything they assume is not included. Neither outcome serves you.
The brief you send determines the quality of the quotes you receive. A well-structured brief does not require technical expertise — it requires clarity about what you need to achieve and for whom.
What every good brief includes
The problem you are solving
Start with the problem, not the solution. "We need a web app" is a solution. "Our operations team spends three hours per week manually compiling reports from four different systems" is a problem. Developers who understand the problem can propose solutions that fit your actual need — sometimes simpler and cheaper than what you originally envisioned.
Who will use it
Describe your users. Not personas — actual roles. "Three administrators who manage 200 learners across five companies" is more useful than "business professionals aged 35–55". Include how many users, how often they use the system, and whether they are internal staff, external clients, or the public.
The key user flows
Describe the three to five most important things the system needs to do, as step-by-step flows. "Admin logs in → Creates a course → Assigns learners → Learner receives email and completes course → Admin sees completion in a report". This is worth more than three pages of feature lists.
What the system connects to
List every system that the new tool needs to read from or write to. Your CRM, HR platform, payment provider, SSO system. Include whether APIs exist or whether you would need to export/import data. Integration work is one of the largest cost variables in any software project.
What success looks like
What specific, measurable outcome would make this project a success? Reduced manual work hours? Improved completion rates? Faster customer onboarding? Specific, measurable outcomes let developers validate that their proposed solution actually solves your problem.
What you do not need
Be explicit about what is out of scope. This prevents developers from including features you did not want and pricing accordingly.
Timeline constraints
If you have a real deadline, explain why. "We have a product launch in Q2" is context that affects how a project should be staffed and structured. If you have no real deadline, say so — it often reduces cost.
What you do not need in your brief
You do not need to specify the technology stack (unless you have genuine technical constraints). You do not need wireframes (though they help if you have them). You do not need to have figured out the database structure or the API design.
The technical decisions are what developers bring to the table. Your job is to describe the business problem, the users, and the constraints. Leave the rest to the people you are asking to quote.