Most software projects that go badly were mispriced before anyone wrote a line of code. Not because the vendor was dishonest, but because the brief left enough room for two people to read it differently and both feel they were right.
You don't need a technical background to write a brief that closes those gaps. You need to answer a specific set of questions that non-technical briefs almost always skip — and you need to answer them before you ask for numbers, because a vendor's first quote anchors everything that follows.
Here's the structure.
Start with the problem, not the solution
The most common opening line in a software brief is a description of a system. "We need a dashboard that shows..." — and everything downstream inherits that assumption.
Write the problem first, in operational terms:
Every Monday, our operations lead spends roughly four hours reconciling delivery records between the driver app and the accounting system, because the two don't talk to each other. Errors are found an average of nine days late, and we wrote off S$——— in unbilled deliveries last year.
That paragraph does several things a feature list can't. It tells a vendor what success looks like. It establishes whether the project is worth doing at all. And it leaves open the possibility that the answer isn't a dashboard — it might be an integration, or a process change, or an off-the-shelf product that already exists.
If you can't write this paragraph with real numbers in it, that's the first thing to go and find out.
Define who uses it, and what each of them does
List every distinct type of user. For each one, write the two or three things they need to accomplish, in their own words.
| Role | What they need to do | How often |
|---|---|---|
| Operations lead | Reconcile the week's deliveries, flag exceptions | Weekly |
| Driver | Confirm delivery, capture signature, note issues | 20–40×/day |
| Accounts | Export confirmed deliveries for invoicing | Monthly |
The frequency column matters more than people expect. Something done forty times a day needs to be fast and forgiving of poor conditions — one-handed, on a phone, in bad light, on patchy mobile data. Something done monthly can afford to be slower and more deliberate. These are different design problems, and a brief that doesn't distinguish them gets a system optimised for the wrong one.
Watch for roles that surface late. "Oh, and management will want to see it" is a new role, a new permission model, and often a new set of screens.
Answer the seven questions that cause overruns
These are the ones non-technical briefs skip, and they account for most of the gap between quoted and final cost.
1. What systems does this need to connect to, and in which direction? Name each system. For each, state whether data flows in, out, or both. Bidirectional sync is dramatically more work than a one-way read, and "integrates with" hides that difference completely.
2. What existing data needs to come across? How many records, in what format, going back how far, and how clean is it? "We'll export from the old system" is not an answer until someone has actually looked at the export.
3. Who is allowed to see and do what? Permissions are cheap to design up front and expensive to retrofit. If any user must be prevented from seeing certain records, say so now.
4. What personal data does this handle? Names, contact details, identification numbers, location history, anything about employees or customers. PDPA obligations apply regardless of company size, and sector-specific requirements may apply on top. This shapes architecture from the start.
5. What happens when it's offline or something fails? Does the driver app need to work without signal? If the accounting system is down when a sync runs, what should happen? Failure behaviour is real functionality and it needs to be specified, not discovered.
6. How many people and how much data, in two years? Not a precise forecast — an order of magnitude. Ten users or ten thousand. Hundreds of records a month or millions. This changes technical decisions early and is expensive to change later.
7. Who maintains this after launch? Do you have anyone technical internally? If not, the handover needs to account for that, and someone needs to be responsible for updates, backups and the inevitable small breakages.
Write down what you are not building
This is the highest-value section of any brief and the one most often missing.
Out of scope for this phase:
- Customer-facing mobile app (web only)
- Automated invoice generation (export to accounting system is sufficient)
- Historical data before January 2025
- Multi-currency support
- Any changes to the existing accounting system itself
Every item you list here is an argument you don't have in month three. It also tells a vendor you've thought seriously about the project, which changes the quality of the response you get.
If you're unsure whether something belongs in scope, put it in the out-of-scope list with a note. It's far easier to add something back deliberately than to discover mid-build that you and your vendor disagreed about it all along.
Separate must-have from want
Sort every feature into three buckets:
- Must have — without this the system doesn't solve the problem
- Should have — meaningful value, but launch is possible without it
- Later — genuinely wanted, explicitly deferred
The discipline is in keeping "must have" short. If everything is a must-have, you've communicated nothing, and the first budget pressure will force the prioritisation anyway — just later, faster and worse.
A test that works: if we launched without this, what specifically would break or go unlearned? "Nothing, but people would want it" means it isn't a must-have.
Set constraints honestly
State your real budget range and your real deadline, including what drives the deadline.
There's a widespread belief that revealing budget invites vendors to price up to it. In practice, withholding it wastes everyone's time — you receive proposals that are wildly unaffordable or that solve a much smaller problem than you meant, and you go around again.
A vendor who knows you have S$40,000 and a hard March deadline can tell you what's achievable within it, or tell you honestly that it isn't. Both are useful. Neither is available if they're guessing.
Also state constraints that aren't money or time: existing systems you can't replace, internal policy requirements, a technology your team already supports.
Then, and only then, ask for quotes
Send the same document to every vendor. Ask each to respond with:
- Their understanding of the problem, in their own words (this alone reveals a great deal)
- What they'd build and what they'd explicitly exclude
- Assumptions they've made where your brief was unclear
- Cost, and what triggers a change to it
- Timeline, including what they need from you and when
- Who owns the code and IP on delivery
- What happens after launch
That fifth-from-last point deserves emphasis. A vendor who returns a list of assumptions has actually read the brief. A vendor who returns only a number and a timeline has pattern-matched it to a previous project.
When you can't answer these questions
Sometimes you genuinely can't. You don't know how many records are in the old system, nobody's sure what the accounting integration would involve, and the permission model depends on decisions the team hasn't made.
That's a normal position to be in, and the wrong response is to guess and hope the vendor catches it. Guessed answers become quoted assumptions, and quoted assumptions become change requests.
The right response is to treat scoping as its own piece of work, done before the build is committed. Investigate the integrations, look at the actual data, make the decisions, and produce a specification precise enough to quote against — one you own and can take to any vendor.
That's the entire premise of a fixed-scope discovery sprint. You end up with a document, a technical approach and a costed plan, and you're free to build it with whoever you like.
A brief template
Copy this:
1. THE PROBLEM
What is happening now, what it costs, how we measured that.
2. WHAT SUCCESS LOOKS LIKE
The specific number that changes, and by when.
3. USERS
Each role, what they do, how often.
4. MUST HAVE
5. SHOULD HAVE
6. LATER
7. INTEGRATIONS
System | Direction | What happens on failure
8. EXISTING DATA
Source, volume, date range, known quality issues.
9. PERMISSIONS
Who can see what, who can do what.
10. PERSONAL DATA
What is handled, any sector requirements.
11. SCALE
Users and data volume, now and in two years.
12. OUT OF SCOPE
Explicit list.
13. CONSTRAINTS
Budget range, deadline and what drives it, systems we can't change.
14. AFTER LAUNCH
Who maintains it, what support we need.
Frequently asked questions
Do I need to specify the technology? No, unless you have a genuine constraint — an existing stack your team supports, or a platform requirement. Specifying technology without a reason narrows your options and occasionally forces a bad fit.
How long should a brief be? Long enough to answer the fourteen sections above. For a small project that's often three or four pages. Length isn't the measure; unanswered questions are.
Should I ask for a fixed price or hourly? Fixed price transfers risk to the vendor and requires a tight scope — which is why the scoping work has to happen first. Time-and-materials is more flexible but the risk sits with you. Fixed price is generally the safer choice when you can define the work; if you can't define it yet, that's a signal to scope before you commit either way.
What if a vendor says the brief is too rigid? That's worth listening to. A good vendor will push back on specific requirements they think are wrong, and explain why. That's different from wanting the brief to stay vague.
If you've worked through this and hit questions you can't answer internally, that's exactly what Planning & Scoping is for: a fixed-scope engagement that produces the specification, technical approach and costed plan — yours to keep, whoever builds it.