A brief is not a specification
People often put off contacting a developer because they think they need a detailed specification first: every screen, every field, every button. You do not. Writing one is the developer's job, and a good one will want to work it out with you rather than inherit it.
What a developer needs from you is enough understanding of the problem to tell whether it is worth solving, roughly what solving it involves, and roughly what it would cost. Two or three pages usually does it. A page is fine if that is all there is to say.
The rest of this guide is a list of what to put in those pages.
Describe the problem, not the solution
This is the most useful thing in the whole brief, and the part most often skipped. "We need an app with a dashboard and a login" tells a developer almost nothing. "Our engineers fill in paper job sheets, the office types them into a spreadsheet at the end of the week, and we never know what state a job is in until it is too late to do anything about it" tells them nearly everything.
That second version is roughly the problem behind our field job sheets work, and the thing that decided the design was a detail you would only get from the problem: engineers work in basements and plant rooms where there is no signal. A brief that asked for "a mobile app" would have missed it.
So write down:
- What goes wrong now, in concrete terms. What takes too long, what gets lost, what gets done twice.
- What it costs you. Hours a week, errors, jobs that slip, customers who ring to chase. Rough numbers are fine; they help decide what is worth building first.
- What "fixed" would look like. Not screens, but outcomes. "The office knows what state every job is in by the end of the day."
If you already have a solution in mind, include it — it is useful — but label it as an idea rather than a requirement. There may be a cheaper way to the same result.
Who uses it, and what it replaces
List every kind of person who will touch the system: office staff, managers, people out on site, customers, subcontractors, an accountant who needs a monthly export. For each one, say roughly how many there are and what they need to do. The number of different kinds of user is one of the biggest influences on cost, so this section matters.
Then describe what the system replaces. A spreadsheet, a paper form, an old system, a WhatsApp group, a product that almost fits. Attach an example if you can: a copy of the spreadsheet with the real columns, a photo of the paper form, a few screenshots. A developer can learn more from ten minutes with a real spreadsheet than from any description of it.
Name the person who currently lives in that spreadsheet. They know the exceptions, and the exceptions are where software goes wrong.
Must-haves and nice-to-haves
Split what you want into two lists, and be strict about the first one.
A must-have is something without which the system is not worth switching to. A nice-to-have is something you would like, and would happily have in a second phase. Most first briefs put nearly everything in the first list, and most first builds go better when half of it moves to the second.
This split is also what lets a developer give you options: here is the price for the must-haves, here is what the rest adds. That is far more useful than a single number for everything.
Integrations and data
Two areas that routinely add cost when they are discovered late:
- Integrations. Which systems does this need to talk to? Accounting, payments, a CRM, email, a supplier's portal. Say which product and, if you know it, which plan you are on. "It needs to create invoices in our accounting software" is a real piece of work and should be in the brief, not mentioned in week six.
- Existing data. Does anything need to come across from the current system? How much of it, how old, and how tidy is it honestly? Years of records in a spreadsheet that five people have edited is a different job from a clean export.
Mention anything with rules attached as well — personal data, financial records, anything your industry regulates — so it is designed in rather than bolted on.
Budget and deadline
Include a budget range. People leave it out because they worry it will be used against them. In practice it is the most useful sentence in the brief: it tells the developer whether to propose the full version, a smaller first phase, or an honest "this is not enough to do it properly". Without it, you get a quote for whatever the developer imagined, which may be twice what you can spend. The cost guide has real ranges if you need a starting point.
Include a deadline and the reason for it. "By March" is less useful than "by March, because that is when the current system's licence runs out". A real reason lets the developer plan around it, and tells them which parts must be ready by then and which can follow.
It is also worth saying, up front, that you expect the code, hosting and accounts to be in your name. Who owns the code explains why.
Where to send it
If you have got this far, you have most of a brief already. Send us whatever you have through the contact page — a rough page is fine, and so is a paragraph and a spreadsheet. We will read it, ask the questions that matter, and tell you plainly whether it is worth building, roughly what it would cost, and whether we are the right people to do it. If the honest answer is that you should buy something instead, that is the answer you will get.