When a brief says "we need a booking app like the ones everyone uses", estimates that come back can differ by a factor of five. Not because some teams are dishonest, but because each fills the gaps with different assumptions. The more of those gaps you fill, the more accurate and comparable the estimates become.
A good brief does not need to be long. Three to six pages usually cover everything. Here is what to include, based on the briefs that have led to our most accurate estimates.
1. Why the project exists
Start with the problem and the goal. What is not working today? What would success look like in six or twelve months? Is this a new product, a replacement for an existing system or an addition to one? A team that understands the goal can suggest cheaper ways to reach it, and can tell which features are essential.
2. Who will use it
List each type of user: customers, staff, managers, admins, partners. For each, write a sentence on what they need to do. The number of user types, and how different their permissions are, is one of the biggest drivers of cost, so this section matters.
3. The main workflows
Describe the three to five most important things users do, step by step, in plain language. For example: "A customer searches for available times, picks one, pays a deposit and gets a confirmation email. Staff see the booking in a calendar and can move it." Workflows tell a team far more than a list of features.
4. Features, split into must-have and later
List features in two columns: what the first version must have, and what can wait. Be strict. Every must-have adds cost and time. If you are unsure, mark it as later; it is much easier to add a feature than to remove one after it is built. Our guide on planning an MVP helps with this split.
5. Other systems it must connect to
Name every system the product needs to exchange data with: CRM, accounting, payment provider, calendar, email, your existing database. For each, say what data moves and in which direction, and whether you know if it has an API. Integrations are where estimates most often go wrong, so detail here pays off.
6. Existing data
Will the new product start empty, or does data need to move from spreadsheets or an old system? Roughly how much, and how clean is it? Data migration is frequently underestimated, and knowing about it early makes the estimate honest.
7. Constraints and requirements
- Budget range: even a rough range helps a team propose the right scope.
- Deadline: and whether it is fixed or flexible, and why.
- Platforms: web, iOS, Android, desktop.
- Rules: privacy, industry regulations, accessibility requirements.
- Technology: any preferences or existing systems the team must work with.
- Hosting: where the product should run and who will manage it.
8. AI features, if any
If the product includes AI, describe the task precisely: what the AI reads, what it produces, how accurate it needs to be and what happens when it is wrong. "Add AI" cannot be estimated; "summarize each support ticket in three bullet points for the agent" can. See how to brief an AI development team.
9. Examples you like and dislike
Links to products whose design or flow you admire, and ones you do not, save a lot of back and forth. Say what specifically you like about each.
10. After launch
Who will maintain the product? Do you expect ongoing development? Will your team take it over? This affects how the product should be built and documented, and it changes which engagement model fits. See engagement models.
11. What you do not know yet
List open questions honestly. "We have not decided on pricing" or "we are unsure whether we need a mobile app" are useful to know. A good team will propose how to answer them, sometimes with a short discovery phase before the main estimate.
What not to worry about
You do not need to choose technologies, design databases or write technical specifications. That is the development team's job. Focus on the business: who, what, why and under which constraints. Technical detail from you is welcome if you have it, but it is not required for a good estimate.
Using the brief to compare proposals
Send the same brief to every team you are considering. Then compare how each responds: do they ask good questions, state their assumptions and name risks? A proposal that repeats your brief back with a number attached tells you little. One that challenges an assumption or suggests a cheaper route tells you a lot. See questions to ask before hiring a software agency.
What we do with a brief
When we receive a brief, we read it, list our questions and schedule a short call. After that, we send a written scope with assumptions, risks and a plan in milestones. The first milestone comes with a fixed-scope estimate. For the full process, see how we work and pricing and estimates.
A quick template
- Problem and goal
- Users and what each needs
- Main workflows, step by step
- Must-have and later features
- Integrations
- Existing data
- Constraints: budget, deadline, platforms, rules
- AI features, precisely described
- Examples
- After launch
- Open questions
For a longer version, read how to write a software requirements document. When your brief is ready, send it to us.
