Most software that disappoints was built exactly as asked. The request described a solution, the company built that solution, and the problem behind it stayed where it was.
A good brief describes the problem and leaves room for the people building it to find a better answer than the one you first imagined.
01What a brief needs, on one page
- The problem, in a sentence, and what it costs you today.
- Who will use the software, and what each kind of user must be able to do.
- What already exists: the systems, spreadsheets and habits it replaces or joins.
- The must-haves, separated honestly from the nice-to-haves.
- Constraints: where data must stay, deadlines that are real, the budget range.
- How you will know it worked: the number or the behaviour that should change.
02Describe tasks, not screens
"A dashboard with six charts" is a screen. "A store manager needs to see by nine each morning which items will run out this week" is a task. The second tells the designer what matters and lets them propose something better than six charts.
03Mistakes that cost the most
- Everything marked essential. If nothing can be cut, nothing has been decided.
- No user named. "Staff" is not a user; a dispatcher on a phone in a yard is.
- Hidden systems. The spreadsheet that really runs the process surfaces in week six.
- No owner. One person on your side must be able to answer questions and make decisions.
- A deadline with no reason. Say why the date matters and the plan can be shaped around it.
04What to expect back
- Questions. A company that asks none has not understood, or does not intend to.
- A written specification you can read and correct before anything is built.
- A plan in stages, each ending in something you can see and use.
- A price tied to the scope, and a clear rule for changes.
- A statement of who owns the code.
05During the build
See working software early and often. A short review every week or two, on the real thing rather than slides, catches misunderstandings while they are cheap. Changes are normal; what matters is that each one is written down with its effect on price and date.
In short
- Brief the problem and the tasks, not the screens.
- One page: problem, users, existing systems, must-haves, constraints, measure of success.
- Name one decision-maker on your side.
- Expect questions, a written specification, staged delivery and clear ownership of the code.
Questions
Do I need a technical person to write the brief?
No. The brief is about the business problem. A good development company turns it into the technical specification and shows it to you in plain words.
How detailed should it be?
One or two pages. Enough to explain the problem and the limits. Detail belongs in the specification that follows.
What if I do not know what I need?
Say so, and describe the problem. Working out what is needed is a legitimate first stage, and it should end in a document you could take to anyone.
How does Quantum Beetle start a software project?
With the specification first, agreed in writing, then delivery in visible stages. You own the code.
Sounds like your problem?
Tell us about it. We'll say honestly whether the swarm can help, and what it would take.
Read next
- Website, web app, mobile app or custom software: how to choose what to buildSoftware development
- What a web application security test covers, and what to ask forSecurity testing
- How to get your company cited by ChatGPT, Perplexity and Google AI OverviewsAI marketing · GEO
- What a website costs: the eight things that decide the priceWebsites
- Custom software or an off-the-shelf product: which one fits your businessCustom software
- Native or cross-platform: how to choose for a mobile appMobile apps