A good brief saves weeks of back-and-forth and gets you a more accurate price. It doesn't need to be technical, and it fits on one page. Here's what to put in it, what to leave out, and a template you can copy.
Why the brief matters
Developers price what they can picture. A vague brief gets you a vague quote, usually with a big safety margin added. A clear brief about the problem gets you a sharper price, fewer surprises and a product that does the right job.
The good news: you're the expert on the problem, and that's what a brief is mostly about. You don't need to know anything about code.
What goes in
- The problem. What goes wrong today, in two or three sentences. Be specific: "Reports take four evenings a week" is better than "Reporting is inefficient".
- Who has it. The person who feels the pain, and roughly how many people like them there are.
- How it's done now. The spreadsheets, paper forms, WhatsApp groups or software people use today, and where it breaks.
- The one job. The single thing the first version must do well.
- Must-haves. A short list of what it can't work without.
- Who uses it, and where. In an office? On site with a poor signal? On a phone with gloves on? This changes a lot.
- What success looks like. How you'll know it's working, in plain terms: time saved, fewer mistakes, people paying.
- Budget and timing. A range is fine. It helps the developer suggest what fits rather than guess.
- What you already have. Sketches, example reports, a list of interested customers, a name, a logo.
- Rules to follow. Anything about data, health, finance or your industry's regulations.
What to leave out
- Which technology to use. Leave that to the developer, and ask them to explain their choice in plain English.
- Every feature you can imagine. Put the extras in a "later" list so they're not lost, but keep them out of the first version.
- Pixel-perfect designs. Rough sketches of the key screens help. Polished mock-ups usually get redone anyway.
A one-page template
Copy this into a document and fill it in. Short answers are fine.
Project brief
- The problem: …
- Who has it, and how many: …
- How it's done today: …
- The one job the first version must do: …
- Must-haves: …
- Later (not in the first version): …
- Who uses it, on what device, where: …
- How we'll know it's working: …
- Budget range and ideal launch date: …
- What I already have: …
- Rules or regulations to follow: …
A filled-in example
Example · Check-in reports for a letting agent
- The problem: check-in and check-out reports take three hours each to write up, and disputes over deposits drag on because photos aren't linked to rooms.
- Who has it: inventory clerks and small letting agents. There are thousands across the UK.
- How it's done today: photos on a phone, notes on paper, typed into a Word template in the evening.
- The one job: walk the property room by room on a phone and have the report ready to send when you leave.
- Must-haves: rooms and items checklist, photos attached to each item, condition ratings, tenant signature, PDF report.
- Later: comparing check-in with check-out automatically, a landlord portal, links to letting software.
- Who uses it: one clerk, on a phone, in properties that often have no signal.
- Success: reports done on site, in under an hour.
- Budget and timing: £15,000 to £25,000, live before the summer moving season.
Questions to ask the developer back
- What would you leave out of the first version, and why?
- What's the fixed price, and what exactly does it include?
- When will I see something working?
- Who owns the code and the product when it's done?
- What will it cost to run each month, and to maintain?
A good developer will push back on parts of your brief. That's a good sign: it means they're thinking about your problem, not just the list.
Next step
You don't need a perfect brief to talk to us. A short paragraph about the problem is enough to start. See what goes in a first version for help with the must-have list, or tell us your idea.