Why Your Brief Matters More Than You Think
Most inaccurate software quotes aren't the development company's fault. They're the result of a brief that was too vague to quote accurately. When requirements are unclear, developers estimate conservatively — or they underestimate to win the work and recover costs through change requests later.
A well-written brief does three things:
- It forces you to think clearly about what you're actually building
- It gives development companies enough information to quote accurately
- It creates a reference point for the project that reduces miscommunication later
This guide covers what a brief needs, the common mistakes that undermine quotes, a worked structure you can use, and what happens when you skip it.
What a Good Brief Needs
1. Problem statement
Start with the problem you're solving, not the solution you've decided on. "We need a web portal" is not a problem statement. "Our operations team spends 15 hours a week manually reconciling data between two systems" is a problem statement.
The clearest briefs explain:
- What the current situation is
- What's wrong with it (the pain, the inefficiency, the risk)
- What success looks like — the outcome you're trying to reach
This context shapes every technical decision that follows. Development teams who understand the problem make better choices. Those who don't will build to the letter of your requirements and miss the point.
2. Who the users are
Describe who will use this software. Not demographic profiling for its own sake — practical specificity that affects design and build decisions.
- Are users your internal team or external customers?
- What's their technical comfort level?
- Are they using mobile devices, desktops, or both?
- How many users are expected, and will that number grow significantly?
- Are there different user types with different permissions or workflows?
A system used by 10 internal logistics coordinators on desktop is built very differently from a mobile-first consumer app targeting 50,000 users at launch.
3. Core user journeys
Describe the two or three things users most need to do in the system. Not every feature — the critical paths that deliver the core value.
A good format: "A [user type] needs to be able to [do this action] so that [outcome]."
For example:
- "A customer needs to be able to submit a new order and track its status so that they don't need to call our team for updates."
- "A finance manager needs to be able to generate a monthly reconciliation report without manual data entry."
These journeys anchor the scope. Everything else is either in service of them or it isn't.
4. Technical constraints and existing systems
If you have existing infrastructure, describe it. Development companies need to understand:
- What systems currently exist and what technology they're built on
- What must be integrated with or replaced
- Any technical constraints the solution must work within (cloud provider, operating system, browser requirements, accessibility standards)
- Whether data migration from existing systems is needed
Integrations with existing systems are one of the most common sources of cost underestimation. Be explicit about what you have.
5. Integrations required
List every third-party system the new software needs to connect with — payment providers, CRM, ERP, accounting systems, APIs, identity providers. Each integration has a cost. Omitting them from your brief means they'll be scoped as change requests later.
For each integration, note whether it's well-documented and has an official API (straightforward) or legacy, internal, or poorly documented (significantly more complex).
6. Timeline expectations
When do you need this? Be realistic and explain the driver if there is one — a product launch, a contract start date, a regulatory deadline. Development companies will tell you whether your timeline is achievable and what trade-offs would be needed to hit it.
Artificial urgency doesn't help. A supplier who says "yes" to an impossible timeline without pushing back is a supplier who'll miss it.
7. Budget range
This is the single most common omission — and the most damaging one. Without a budget range, development companies either have to guess what's feasible or present options across a wide range, neither of which is efficient.
You don't need to state your maximum. Stating a range ("our budget for the initial build is £40,000–£60,000") allows suppliers to scope appropriately and be honest about what that budget can and can't achieve.
Withholding budget information doesn't protect you in negotiation. It just wastes everyone's time and produces quotes that are useless for comparison.
8. Success criteria
How will you measure whether this worked? Concrete criteria help everyone stay aligned on what matters.
Examples:
- "Operations team time spent on reconciliation drops from 15 hours to under 2 hours per week"
- "95% of customer orders tracked without a support call within 90 days of launch"
- "Finance reports generated in under 5 minutes with no manual steps"
Success criteria aren't always fully quantifiable, but the effort of articulating them forces clarity about what the software needs to actually do.
Common Mistakes That Undermine Quotes
Too vague
"We need a platform to manage our operations" could describe a £20,000 project or a £500,000 one. Vague briefs produce wide, hedged estimates that are useless for planning. Development companies add buffer to protect themselves from things you haven't described.
Too prescriptive about solutions, not problems
Briefs that specify technology stack, database architecture, and implementation patterns before the development team has been engaged are doing the supplier's job for them — often badly. Focus on the outcomes you need. Let technical experts propose the how.
No budget given
See above. This is the most common omission and it reliably produces inaccurate quotes.
Listing every feature you'd ever want
A feature list with 60 items is not a brief — it's a wishlist. Prioritise ruthlessly. What are the must-haves for launch? What would be nice but isn't essential? What can wait? A brief that distinguishes between these gets you useful quotes. One that doesn't creates false scope expectations.
No mention of existing systems
Many first-time buyers of software forget to mention the systems they already use. Every integration is scope. Omitting them is how projects end up 30% over budget.
Worked Brief Structure
Here's a structure you can follow directly:
Project name: [What you're calling it internally]
Problem statement: [What's wrong with the current situation and what success looks like]
Users:
- Primary users: [Who, how many, technical level, device preference]
- Secondary users: [Any other user types and their needs]
Core user journeys:
- [User type] needs to [action] so that [outcome]
- [User type] needs to [action] so that [outcome]
- [User type] needs to [action] so that [outcome]
Existing systems and constraints:
- [System 1] — [technology, must be integrated / replaced / works alongside]
- [System 2] — [technology, relationship to new system]
- [Any technical constraints — cloud provider, compliance requirements, etc.]
Integrations required:
- [Third-party system] — [what it does, whether it has a documented API]
- [Payment provider, CRM, ERP, etc.]
Data migration:
- [What data needs to move, from where, approximate volume, current quality]
Timeline:
- Target launch: [date or period]
- Drivers: [why this date matters, if applicable]
- Flexibility: [is there any, and under what conditions]
Budget:
- Range: £[X] – £[Y] for initial build
- Ongoing budget: [if there is a separate view on maintenance and running costs]
Success criteria:
- [Measurable outcome 1]
- [Measurable outcome 2]
Out of scope (if known):
- [Things you've explicitly decided not to build in phase 1]
What Happens When You Skip It
Skipping the brief doesn't save you time. It shifts the cost of clarity to later in the process — where it's much more expensive.
Without a brief, development companies will spend your first paid engagement writing the brief themselves. That's fine if you understand that's what discovery is and budget for it. It's not fine if you expected that engagement to produce working software.
More commonly, projects without clear briefs begin with misaligned expectations and spend weeks resolving ambiguity. Scope disputes are more likely, change requests more frequent, and the final product more likely to miss the mark — not because of incompetent development, but because the target was never clearly defined.
A good brief takes two to four hours to write properly. That investment is returned many times over in more accurate quotes, smoother delivery, and a product that actually solves the problem you had.
Need help with your project? Get in touch — we respond within 24 hours.