How to Brief a Software Vendor (and Get Comparable Quotes)
A vague brief does not get you a cheap quote — it gets you a padded one, because the vendor is pricing the risk of not knowing what you want. Three pages written properly will change both the price you are quoted and what you receive. Here is exactly what goes in them, including the commercial clauses SMEs forget.
Most SMEs approach vendors with a conversation rather than a document, and then wonder why three quotations are impossible to compare. They are impossible to compare because they are pricing three different understandings of the job. A vague brief does not produce a cheap quote — it produces a padded one, because a competent vendor prices the risk of not knowing what you want, and an incompetent one quotes low and recovers it through change requests. Three pages, written properly, changes both the price and what you get.
The eight sections of a brief that works
You do not need a formal tender document. You need these eight things written down, in this order.
1. Context, in five sentences
What the business does, how big it is, who the customers are, and what has changed to make this project necessary now. Vendors make better proposals when they understand the business, and this is where you find out whether they read anything.
2. The problem, with numbers in it
Not "we need a system". Instead: "Three staff spend around two hours a day re-entering orders from WhatsApp into the accounting system. We make roughly eight data-entry errors a month, each taking about an hour to unwind."
This is the most important paragraph in the document. It lets a good vendor propose something you had not thought of, and it gives everyone — including you — a way to judge afterwards whether the project worked.
3. Who uses it, and where
User types, roughly how many of each, and the conditions. "Fifteen field staff on Android phones, often with poor signal" is a design constraint that changes the entire build. So is "one accounts person, on a desktop, all day".
4. Scope, split into must / should / could
| Priority | Meaning | Rule |
|---|---|---|
| Must | The project is pointless without it | Keep this list short — if everything is a must, nothing is prioritised |
| Should | Important, but the first version could ship without it | This is where you negotiate |
| Could | Genuinely nice to have | Expect these to be dropped, and be fine with it |
Splitting the list this way is what makes phasing possible, and phasing is the main lever you have on cost.
5. Integrations, named specifically
List every system this must talk to, by name and version: accounting software, payment gateway, courier platform, POS, marketplace. For each, say whether an API exists and whether you have access to it. Integrations are the single most common cause of overrun, and undeclared ones are the most common cause of a quote turning out to be wrong.
6. Constraints
Hard deadlines and why they are hard. Budget range — yes, give one. Vendors are not able to propose sensibly against an unknown budget, and withholding it produces proposals that are irrelevant in both directions. Also state anything non-negotiable: hosting location, data residency, language requirements, accessibility, compliance obligations such as e-Invoice or SST treatment.
7. How you will judge success
Three measures, tied to the numbers in section 2. "Order entry time reduced from two hours to twenty minutes a day", "data entry errors under two a month", "all staff using it without support after two weeks". Without this, "done" becomes a matter of opinion at exactly the moment opinions diverge.
8. Commercial terms — the section SMEs skip
State these in the brief, so that they are priced in rather than negotiated after you are committed:
- Who owns the intellectual property in the delivered work.
- Source code: will you receive it, and will it live in a repository you own from day one? Ask for this — it is the single most valuable clause for a small business, and it is much harder to obtain later.
- Data: it is yours, exportable in a documented format, on request and at exit.
- Acceptance criteria and a testing period before final payment.
- Payment milestones tied to deliverables, not to dates.
- Warranty period for defects, and what support costs after it.
- What happens if you part ways mid-project — handover of code, credentials and documentation.
Running the selection
- Send the same document to three vendors. Same document, not three conversations.
- Allow questions, and share every answer with all three. A question one vendor asks usually exposes a gap in your brief that the others have silently assumed something about.
- Ask each to state their assumptions. This surfaces the differences that make quotes non-comparable.
- Ask what they would remove to halve the price. The most informative question you can ask — it reveals what they consider essential and how well they understood you.
- Compare scope first, price second. Line the proposals up feature by feature before you look at the totals.
- Talk to a reference from a business your size. Large-client experience does not automatically transfer to a small budget with no internal technical team.
Two mistakes worth naming
Specifying the solution instead of the problem. "We need a mobile app" may be wrong; the problem may be solvable with a mobile-friendly web page in a tenth of the time. Describe the problem and let vendors propose — then judge the proposals. If you have already fixed the solution, run the build vs buy framework first and make sure you fixed it correctly.
Hiding the budget. Owners withhold it fearing the quote will expand to fill it. What actually happens is that vendors propose blind: one proposes something you cannot afford, another something too small to work, and you cannot compare either. A range — "we are thinking in the region of X to Y" — produces better proposals from everyone. If you have no idea what the range should be, what software really costs in Malaysia will get you close enough to start.
Frequently asked questions
How long should the brief be?
Three to five pages for a typical SME project. Longer is not better — a fifty-page document that nobody reads is worse than three pages everyone does. Precision matters more than length, particularly in sections 4 and 5.
Should I really tell vendors my budget?
Yes, as a range. The fear that the price will expand to meet it is real but manageable — you are comparing three quotes, and a vendor who simply quotes your ceiling with less scope than the others is easy to spot when you compare scope first.
What if I do not know what I need technically?
That is normal and it is not a blocker. Describe the problem, the users and the constraints in business language. Any vendor who cannot work from that and needs you to specify the technology is not offering much beyond execution — and if the decision genuinely needs technical judgement you do not have, see when do you need a CTO.
Is it fair to ask three vendors to quote unpaid?
For a normal proposal, yes — it is standard practice. If you want substantial design or discovery work up front, pay for it, and be aware that a paid discovery phase with one vendor often produces a much better brief for everyone, including the vendors you did not choose.
Should I use a formal RFP template?
A template helps you not forget the commercial clauses in section 8, which is where SMEs lose most. But adapt it — an enterprise procurement template applied to a RM30,000 project produces a document that serious small vendors will decline to respond to.
Sources: this guide is commercial and procurement practice rather than a statement of law. The intellectual property, source code, data and acceptance provisions described are contractual matters — for a contract of material value, have the terms reviewed by a legal adviser rather than relying on a checklist.
Estimate it in under a minute with our free calculator.