Most briefs produce quote ranges rather than quotes. That is not the agency being evasive; it is them telling you honestly that the brief left too much undecided.
Here is what to include so that does not happen.
The seven things every developer needs
Your brief
- The problem, in plain languageWhat is going wrong today, and what it costs you. Not the solution.
- Who uses itHow many kinds of user. This is the single biggest driver of cost.
- The one core actionThe thing the product exists to let someone do.
- What it has to connect toExisting systems by name. This is where estimates go wrong.
- Any regulatory constraintHealth data, children's data, financial regulation, accessibility requirements.
- Your budget, honestlyWithholding it does not get you a better price. It gets you a proposal for the wrong project.
- Your deadline, and what happens if you miss itA real date changes the shape of the answer.
What to leave out
The technical approach. Do not specify the database, the framework, or the architecture unless you have a genuine constraint. You are paying for that judgement.
Every feature you have ever imagined. A twenty-page brief gets a large quote, because size signals uncertainty. How to cut it down.
Competitor clones. "Like Uber but for X" tells a developer almost nothing and quietly implies a £200,000 scope.
Precise screen designs. Unless design is settled, describing screens locks in solutions before the problem is understood.
Say your budget
The two-page template
1. The problem
What happens today, and what it costs us.
2. The outcome
What "solved" looks like, in one sentence.
3. Users
Who uses it, and what each type needs to do.
4. The core action
The single thing the product must let someone do.
5. Must connect to
Named systems. Note whether each has an API.
6. Constraints
Regulatory, technical, organisational.
7. Budget and deadline
The real numbers, and what happens if the date slips.
8. Explicitly out of scope
What we are NOT asking for. This section is worth
more than any other for getting an accurate quote.
Section eight is the one almost nobody writes and the one that most improves the quotes you get back.
Common questions
Do I need a technical specification?
No, and writing one is usually counterproductive. Describe the problem and the outcome; let the people you hire choose the technical approach. A non-technical brief that is clear about the problem beats a technical one that guesses at solutions.
How long should an app brief be?
Two pages is plenty. If it is twenty, the scope is too big and the quote will reflect that. Brevity in a brief is a sign of clarity, not of laziness.
Why do I keep getting quote ranges instead of prices?
Because the brief leaves the scope open. A quote range is an agency telling you honestly that they do not know how much work this is. Fix the scope and the range narrows.