A good brief gets you better proposals, faster, and fewer misunderstandings later. A bad one, or none, means every company guesses differently and you cannot compare them. The good news: a useful brief fits on a page, and you do not need to be technical to write one.
What a brief is (and is not)
A brief describes the problem and context. It is not a specification of screens and database tables. Describing the problem well leaves room for the developer to suggest solutions you had not thought of.
The template
Copy these headings and answer each in a few sentences.
1. Background. Who you are, what you do, and how big the team is.
2. The problem. What is going wrong or taking too long? Try to say it in one sentence, then add detail.
3. Who is affected. The people who deal with the problem: staff, customers, managers. Roughly how many of each?
4. How it works today. The current process, tools and spreadsheets. Describe it as it really is, not as it should be.
5. What good looks like. If this were solved, what would be different? "Quotes go out the same day" is a good outcome. "A modern app" is not.
6. Constraints. A deadline? A budget range? Existing systems that must connect? Compliance or data protection concerns?
7. Out of scope. What you are not asking for. This prevents scope creep before it starts.
8. What you do not know yet. Honest questions are valuable. They tell the developer where to dig.
A short, illustrative example
Background: A twelve-person trades business. Problem: We lose track of which jobs have been quoted and invoiced. Affected: Two office staff, five on the road, two directors. Today: A whiteboard, a shared spreadsheet and text messages. Good looks like: One place to see every job's status; quotes out the same day. Constraints: Must work on phones; connects to our accounting package. Out of scope: Payroll. Unknowns: Whether our accounting software can be connected.
That is under 100 words and already far more useful than "we need a job management app".
Common mistakes
- Describing a solution instead of a problem. "We need a mobile app" closes doors. "Our staff can't update jobs from site" opens them.
- Hiding the awkward parts. The messy spreadsheet and the unofficial workaround are exactly what the developer needs to see.
- Trying to specify everything. Priorities matter more than completeness.
- Skipping the people. Say who will use it and how they feel about change.
What to do with it
Send the same brief to two or three companies and compare how they respond. The best responses ask thoughtful questions rather than rushing to a price. Our post on choosing a software company covers what else to look for.
Ready to try it? Send us your brief, even a rough one. We will tell you honestly what we think.