How to write a development brief that gets you a range instead of «it depends»
Briefs that produce an estimate immediately and briefs that produce a week of back and forth do not differ in length. A multi page description is often less useful than five paragraphs if it misses a handful of specific answers.
Here is what usually stalls an estimate, and what to write so it does not.
The problem, not the product name
«We need a website» is a format, not a problem. A problem sounds like this: «we lose enquiries because they arrive in three different messengers and some go unanswered», or «we want to sell to our own customer base without the aggregator’s commission».
The difference is practical. A format only implies markup. A problem implies what counts as success and what can be skipped. For a company selling water use permits, the problem was collecting enquiries in one place, which is why the project ended up with a pricing calculator, two forms, and automatic delivery of enquiries into a spreadsheet and a Telegram channel. Everything else could be left out.
A user scenario instead of a feature list
Feature lists look useful and estimate badly. «A personal account» is both a page with order history and a role based permission system with report exports, and the difference between them is several times the budget.
Describe one person’s path step by step: where they came from, what they saw, what they clicked, how it ended. From that a vendor assembles the feature list themselves, and you get to see their list instead of trading assumptions.
The list of external systems
This is the item that moves the estimate most. Write down what the product must exchange data with: accounting system, point of sale, CRM, payment provider, stock levels, delivery.
For a wholesale flower supplier’s storefront the list included card acquiring, a sync with the accounting system, plus point of sale and restaurant management platforms. Every line is a separate task with its own surprises, and it is better to learn about them during the brief than in week two.
If there are no integrations, say so. That is information too, and it moves the estimate down.
A deadline with a reason
What helps is not the date but the reason behind it. «As soon as possible» does not help. «We open the office on 15 October» or «our season starts in March» determines what gets cut to make it.
If the deadline is hard, say so immediately. Then the conversation is about which part of the product must work by that date, rather than about fitting the impossible.
A budget frame
The most awkward line in a brief, and the one that saves the most time. A stated frame removes half the conversation.
Honesty runs both ways here. If the budget is one hundred thousand roubles and the task costs four hundred, it is better to know on day one. In that case we say plainly that the task cannot be done for this money, and show which part of it can.
What a brief does not need
No technical specification. If you have no developer in house, the vendor writes it, and that is separate paid work.
No stack selection on our behalf. Occasionally it is justified, more often it is a retelling of somebody else’s advice that constrains the solution for no reason.
No hiding that there was a previous vendor. Knowing what exists and where it stopped saves weeks. A project rewritten from scratch and a project picked up mid flight are different estimates.
A template you can copy
Company: what we do.
Problem: what does not work today, in measurable form.
Scenario: the user path, step by step.
External systems: what we need to exchange data with.
What already exists: design, copy, domain, previous vendor.
Deadline: date and reason.
Budget: a frame, or «waiting for your estimate».
Contact: name, Telegram or email.That is enough to get a range and a list of assumptions on the first call.
There is a flip side agencies rarely mention: a brief also shows whether a project will be heavy. When the answer to «what is the problem» describes an interface, and it turns out four people sign off and disagree with each other, the issue is not the brief. That is exactly the information we read it for.
FAQ
Do I need a technical specification first
No. A specification is an output of the vendor's work, not an input. What is needed from you is the user scenario and the list of systems the product must exchange data with.
Do I have to name a budget
Not required, but useful. A stated frame removes options that do not fit you and moves the conversation to scope. If there is no frame, say plainly that you are waiting for an estimate, that works too.
What if the requirements are still unsettled
Describe what is known and mark separately what is undecided. Uncertainty in a brief is more honest and cheaper than invented certainty that has to be dismantled in week three.