The more clearly you describe your needs to an agency or software team, the more accurate and comparable the proposals you receive will be. A brief is a short document that explains the purpose, scope and boundaries of a project. It doesn't have to be perfect, but it does have to answer the right questions.
What a brief should include
- Company and context: what does your business do, who are your customers and why are you starting this project now?
- Goals: what will change if the project succeeds? Where possible, write measurable goals (for example, increasing the number of enquiries or shortening order processing time).
- Target audience: who will use the website or software, on which devices and for what purpose?
- Scope: the pages, features and integrations you need. Separate 'must-haves' from 'nice-to-haves'.
- Current situation: your existing website, software, domain, hosting, content and data sources.
- Integrations: which ERP, CRM, accounting, payment, shipping or other systems need to be connected?
- Timing: the target launch date and the business reason behind it (a trade fair, a campaign, the season).
- Budget range: even without an exact figure, sharing a range makes it easier to recommend the right solution.
- Decision process: who has a say in the project, and who gives approvals?
Practical ways to describe the scope
- Write user scenarios: a sentence like 'a dealer should be able to log in, see their past orders and place a new one' is clearer than a long feature list.
- Share examples you like and dislike, and explain why.
- Attach any screenshots, process diagrams, spreadsheets and existing documents you have.
- Mark open points clearly as 'not decided yet'; they can be clarified together during discovery.
Common mistakes
- Describing the solution instead of the problem: rather than 'we need a mobile app', explaining the problem the app should solve leads to better recommendations.
- Trying to fit everything into the first version: long, unprioritised lists strain both the budget and the timeline.
- Dictating technology without a reason: if there is a business reason for requiring a specific technology, write it down; otherwise stay open to the team's recommendation.
- Forgetting content and data preparation: copy, images and data to be migrated are the items most often delayed in projects.
From brief to proposal
A good brief makes the discovery call more productive. In the call we clarify the open points together and then prepare a written proposal covering the scope, deliverables, technology choices and a week-by-week timeline. If you don't have a brief yet, don't worry: the questions in our quote form are designed to take you through these sections step by step.
