Most software projects that go wrong for small businesses don't fail technically. They fail because the brief described a solution instead of a problem, or left the important decisions to be discovered halfway through — by which point they're expensive.
You don't need technical vocabulary to brief well. You need to be precise about six things. Here they are, with what a good answer looks like.
1. The job that isn't getting done
Start with the work, not the software. "We need a dashboard" is a solution. "Nobody knows which customers have stopped ordering until they've gone" is a problem — and it might be answered by a weekly email rather than a dashboard, for a fraction of the money.
Good: "Every Friday someone spends three hours assembling a sales report from four places, and by the time it's done it's out of date."
Weak: "We want a reporting system."
2. Who it's for, by name
Not "the management team" — the actual person who will open it. Their appetite for detail, whether they'll be on a phone, whether they'll ever log into anything. This single answer changes the design more than any technical decision.
If two people with different needs are named, say so explicitly. Building one thing for two audiences quietly produces something that suits neither.
3. The questions it must answer
Write them as literal sentences, in the words the person would use. Five is plenty.
- How did sales do last week compared with normal?
- Which customers have gone quiet?
- What's overdue, and who owes the most?
- Have we got enough stock of the top five lines?
- What needs chasing this week?
Anyone competent can build to that list. Nobody can build to "give us visibility".
4. Where the facts live — and who controls access
List every system involved and who administers each one. You don't need to know whether it has an API; you need to know its name and who can create a login. A brief that says "Xero, our till system, and a spreadsheet Karen maintains" is more useful than one that says "our data".
Flag the spreadsheet explicitly. Nearly every business has one holding something essential, and it's usually the thing that determines how long the job takes.
5. What it must not do
The most valuable line in any brief. "It must not email customers without someone approving it." "It must not change anything in the accounts package." "It must not need anyone to learn a new system."
These constraints are cheap to honour if stated up front and expensive to retrofit. They also tell you a lot about a supplier: one who pushes back on a sensible constraint is telling you something.
6. How you'll know it worked
Not "improved visibility". Something checkable: the Friday report takes nobody any time, or the number of accounts that go dormant without anyone noticing falls to zero, or invoices go out the same day the work finishes.
If you can't state this, the project has no definition of done — and a project with no definition of done will absorb whatever budget it's given.
What you don't need to specify
Which language, which database, which cloud, how it's hosted. Those are the supplier's decisions and their consequences. Specifying them from a position of non-expertise narrows the options for no benefit, and it's the fastest way to end up with something built the way you asked rather than the way that works.
Two exceptions worth stating: where the data may live if you have a genuine requirement, and that you must own whatever gets built.
The one-page brief
All six answers fit on a page. Send it before the first conversation rather than after, and two useful things happen: you find out quickly whether the supplier reads, and you get quotes that can actually be compared, because they're all pricing the same thing.
It also protects you. When a project drifts, the argument is almost always about what was originally agreed. A page written before anyone was invested settles that in about thirty seconds.
The six answers, on one page
Here's what a completed brief actually looks like, for a wholesaler who wanted their Friday reporting to stop existing.
1. The job that isn't getting done. Every Friday someone spends three hours assembling a sales and stock report from Xero, our till system and a spreadsheet. By the time it's finished it's a day out of date, and if that person is away it doesn't happen.
2. Who it's for. Me (owner) and Dan (operations). Both read email on a phone before 8am. Neither of us will log into anything.
3. The questions it must answer. How did sales do last week versus normal, split by product? Which customers have gone quiet? What's overdue and who owes most? Have we got enough stock of the top ten lines? What needs chasing this week?
4. Where the facts live. Xero (Karen administers). EPOS till system (Dan). Stock spreadsheet Karen maintains and nobody else fully understands.
5. What it must not do. Must not email customers. Must not write anything into Xero. Must not require anyone to learn a new system.
6. How we'll know it worked. Friday afternoon stops being spent on this, and we find out about a quiet customer within two weeks rather than two months.
That's the whole brief. Notice it contains no technology, no features, and no solution — and any competent supplier could quote it accurately.
Reading the responses
Once the brief goes out, the responses tell you more than the portfolios do. Three patterns worth recognising.
The one that asks about the spreadsheet. Good sign. They've spotted that the least formal system in the list is the one that will determine the timeline, and they want to know what's in it before committing to anything.
The one that quotes immediately, in full, with confidence. Be careful. Either they've done this exact job before — worth establishing — or they're guessing and will come back for more money. Ask what they'd do if the till system turns out to have no usable API. If there's no answer, they haven't checked.
The one that proposes a platform. Some suppliers answer every brief with the product they resell. That isn't automatically wrong, but the question to ask is what happens to the questions in section three that the platform doesn't cover.
The questions to ask them
Four, and they're the same four regardless of what's being built.
- Who owns what you build? The answer should be you — code, data and infrastructure, in your accounts.
- What happens if it takes longer than you thought? On a fixed price, that's their problem. If the answer involves a day rate, you don't have a fixed price.
- What could make this not work? A supplier who says "nothing" hasn't thought about it. You want to hear about API limits, data quality, and the spreadsheet.
- What happens when something breaks in six months? Establish now whether that's a support arrangement, a favour, or a new quote.
Two things to put in writing before starting
The definition of done. Not "delivered" — a specific observable state. "The report arrives at 7am every Monday containing the five listed questions, and we've checked the figures against Xero by hand once." Without this, the project ends when everyone runs out of energy.
What happens to access at the end. Which keys get revoked, which stay, and in whose account they live. This is trivial to agree at the start and awkward to raise later.
A warning sign worth naming
If a supplier's first response to the brief is enthusiasm rather than questions, be careful. A good response is three or four awkward questions — about the spreadsheet, about what happens when two systems disagree, about who owns the output. Those questions are the job. Enthusiasm is just enthusiasm.