Most software briefs are a feature list with a covering paragraph. They get sent to three suppliers, come back as three quotes that cannot be compared, and the winner is whoever seemed most confident about a plan nobody has examined.
The problem is not that the brief was too short. It is that it answered the wrong question. A brief that specifies a solution asks suppliers to price your guess. A brief that describes a problem asks them to think, and lets you find out which of them can.
Describe the problem, not the answer
The UK government buys a great deal of digital work and publishes its own guidance on how. The core instruction to buyers is direct: you write requirements to tell suppliers about your situation or problem, and they propose a solution that meets your needs [1].
That division of labour is the whole point. You know your business, your constraints and what going wrong costs you. They know what is technically possible, what it costs, and what has failed for other people. A brief that specifies screens, a database structure or a technology stack takes the second set of knowledge off the table and replaces it with the guesses of whoever wrote the document, who is usually the person least equipped to make those calls.
You then buy your own guess, competently executed, and nobody involved had any incentive to tell you it was the wrong guess.
None of this means you cannot express a preference. State it, label it as a preference, and give your reasoning. That lets a supplier agree, or explain what you have not considered, instead of quietly quoting for something they believe is wrong because arguing looked like losing the work.
The nine things a brief needs
What the business does. Two or three sentences. Enough that somebody outside your industry understands who your customers are and how you make money.
The problem, in observable terms. Not "our process is inefficient". Instead: this task happens forty times a week, takes about twenty minutes, involves three people, and roughly once a fortnight a step gets missed and we have to redo it. The second version tells a supplier what to solve. The first tells them only that you are unhappy.
Who is affected, and how often. Which team, how many people, how many times a day. This is what decides whether a build is justified at all.
What you have already tried. The spreadsheet, the off-the-shelf tool you bought and abandoned, the process change that did not stick. Where a stopgap stopped coping, and specifically how, is worth more than any requirements list, because it is evidence rather than speculation.
What success looks like, measurably. "Improve the customer experience" cannot be built against or held to. "Reduce the time from enquiry to quotation from two days to two hours" can.
Your real constraints. Systems it must work with, data that cannot leave the country, a platform you are contractually stuck with, a peak trading season, a regulator, an internal team who will have to maintain it. Half of these are known only to you, and constraints discovered late are the most expensive kind there is.
Budget, as a range. More on this below.
Timing, and why. A date attached to a reason is a constraint. A date attached to nothing is a preference, and suppliers can tell the difference.
Who decides. Name the person who can approve and break ties, and say who else must be consulted. Suppliers price uncertainty, and a project with three stakeholders and no decider genuinely costs more to deliver.
Most briefs contain three of these and a feature list.
Yes, include the budget
The standard advice is to withhold it so suppliers cannot price up to it. That advice costs you more than it saves.
Without a number, every supplier guesses at your scale, and you receive proposals so far apart that comparing them is meaningless. One quotes for a phase-one pilot, another for a platform, and you learn nothing about either except that software prices vary, which you already knew.
With a range, you find out what is achievable at that level, what would have to wait, and which suppliers are willing to tell you the range is not enough. Some will quote to the top of it, and that is information about them. The more useful response is the supplier who explains what fits, what does not, and what they would do differently at a lower or higher figure. You cannot have that conversation when nobody knows the number.
Features are solutions in disguise
If you have candidate features, include them, clearly labelled as ideas rather than requirements. Then split them into the ones you are confident about and the ones you would happily be talked out of, and say which is which.
A bare feature list read as a requirement removes any chance of a supplier proposing something cheaper or better. It also quietly transfers responsibility: once you specified it, they built what you asked for, and the fact that it did not solve the problem is now your issue rather than theirs.
Leave out technology choices you have no basis for, screen designs, database structures, and anything copied from a competitor's product. Leave out the page of company history too. It buries the parts that matter under material nobody quoting needs.
Do mention if you have been let down before. What was attempted, what went wrong, what you learned. Factually, without naming anyone. It genuinely changes how a good supplier approaches the work.
The same brief, written twice
Worth seeing side by side, because the difference is not length.
The version that usually gets sent:
We need a customer portal where clients can log in, view their documents, download invoices, update their details and raise support tickets. It should have an admin dashboard with reporting. Modern design, mobile responsive, integrated with our existing system. Please quote.
Every supplier who reads that will quote for a different thing, because it names six features and no problem. There is nothing to disagree with, nothing to improve, and nothing that tells anyone whether a portal is even the right answer. The quotes come back several times apart from each other, and none of them is wrong, because each is pricing a different imagined project.
The version that gets useful answers:
We are a mid-sized logistics business with about 200 active clients. Our accounts team currently emails invoices and delivery paperwork individually, on request. That is roughly 60 requests a week, each taking about ten minutes to locate and send, and about five a week arrive as complaints because the client could not find an earlier email. Two of our four accounts staff spend a meaningful share of their week on this.
We want clients to retrieve their own documents. Success would be fewer than ten document requests a week reaching the accounts team within three months of launch, and no increase in complaints.
Constraints: documents live in our existing ERP, which we are not replacing; some client data cannot be hosted outside the UAE; we cannot make changes during our November peak. Budget range AED 60,000 to AED 90,000. Decision by our operations director, who can approve without further sign-off.
We think this is a client portal but we are open to being told otherwise. We tried a shared drive in 2024 and abandoned it because permissions were unmanageable.
The second version is longer, but not much, and every extra sentence does work. A supplier can now tell you that half your problem might be solved by automated invoice delivery at a fraction of the cost, or that the ERP integration is the entire risk and should be tested first. Neither of those responses was available against the first version.
Notice also that the second brief is falsifiable. In three months you will know whether it worked.
Decide how you will choose, before you ask
This is the step that gets skipped, and skipping it is why the process feels arbitrary at the end.
Set your evaluation criteria before the brief goes out, state them in it, and do not change them afterwards. Public procurement guidance is strict on exactly this point: criteria and their weightings cannot be changed once requirements are published [1]. The discipline is worth borrowing, because criteria invented after the proposals arrive have a way of describing whichever proposal you already preferred.
Separate essential from nice-to-have, which is how the UK government structures its own digital buying [1], then weight the things you actually care about: understanding of the problem, relevant experience, the proposed approach, the specific people doing the work, and price. Apply the same scoring to every proposal.
Price should not dominate unless the proposals are genuinely equivalent, and for software they almost never are. A cheaper quote usually differs in scope, seniority, testing or post-launch support rather than in efficiency. Our guide on why app quotes vary covers what actually moves the number, and reading it before you score anything will change how you read the low one.
What to ask suppliers for
Seven things, in this order.
Their understanding of the problem, in their own words. The approach they propose and why. What they would do first. Who will do the work, and how much of those people's time you actually get. What they need from you. What they see as the biggest risk. And the price, with its assumptions stated.
The first is the most revealing and the most commonly skipped. A supplier who restates your problem in their own words and adds something you did not say has genuinely engaged with it. One who paraphrases your brief back has read it. One who goes straight to a solution has a template. You can rank three proposals on that alone and be roughly right.
If a supplier proposes something completely different from what you expected, read it properly rather than marking it down for non-compliance. That response is the entire benefit of describing a problem instead of specifying a solution, and penalising it wastes the exercise.
Practical mechanics
Talk to suppliers before you write. In public procurement this is called early market engagement, and it is routine [1]. Two or three conversations before the brief exists will tell you what is normal, what is expensive, and what you have not thought of, while the brief can still change.
Then give everyone the same document. Including anything useful that came out of those early conversations. If one supplier's question improves the brief, share the answer with all of them. It costs nothing and stops the best-connected supplier winning rather than the best one.
Approach three. One gives you no comparison, two gives you a coin toss, five costs you fifteen hours and wastes four suppliers' time. Tell them how many they are competing against, because it changes how much effort a serious supplier will invest.
Allow two weeks. A shorter window filters for suppliers with idle capacity rather than good ones. If you need it faster, cut the number of suppliers rather than the time.
Allow questions, with a deadline. The questions are diagnostic. A supplier who asks nothing has usually engaged with nothing.
Keep it to two to four pages. Long enough to cover the nine items, short enough that people will read all of it. A fifty-page requirements document usually means somebody already did the design work in advance, which is the thing this article is arguing against.
What the brief becomes afterwards
One thing worth planning for at the start: the brief does not stop being useful once you have chosen somebody.
The problem statement, the measurable definition of success, and the constraints should all survive into the contract, because they are what you will judge delivery against. A project that ships something matching the feature list but missing the measurable outcome has failed, and you can only make that argument if the outcome was written down before anybody started.
The candidate feature list, by contrast, should not survive intact. By the time a supplier has done proper discovery, some of those features should have been dropped, merged or replaced by something better. If the delivered scope matches your original guesses exactly, either you were unusually lucky or nobody examined them, and the second is considerably more likely.
It is also worth agreeing at this point what happens to the brief's assumptions when they turn out to be wrong. Not a penalty clause, but a stated process: if discovery finds that the ERP integration is twice the work assumed, do you cut scope, move the date, or increase budget? Deciding the mechanism now is much easier than deciding it in month two under pressure.
When the brief is the hard part
Sometimes you cannot write the problem down, because the business does not yet agree on what it is. That is worth knowing before you commission anything, and our guide on whether it is actually a software problem covers how to test it.
If the problem is real but genuinely unclear, a short paid discovery that produces a written specification starts from around AED 4,000 with us. Final pricing depends on scope. One condition is worth insisting on with anybody who does this work: you own the specification outright and can give it to whoever you like. A discovery you cannot take elsewhere is a sales document, and it converts a competitive process into a single-supplier one without anybody saying so.
A review of a brief you have already drafted starts from around AED 1,500, covering whether it is answerable, where it accidentally specifies a solution, and what a supplier will price as risk because something is missing. These are our own figures rather than a market survey.
For what to do when the responses arrive, our guide on reading a software proposal covers the other side of this exchange.
The free version, and the thing to do first: write the problem in observable numbers. How often, how long, how many people, what it costs when it goes wrong. If you can fill that in, the rest of the brief writes itself. If you cannot, no quantity of feature listing will cover the gap, and a supplier will find it in week two regardless.
References
- GOV.UK, buying through the Digital Outcomes and Specialists framework
- US Digital Services Playbook
- TechFAR Hub, planning for agile
- SKIMBOX, how to read a software proposal
- SKIMBOX, why app quotes vary in the UAE
- SKIMBOX, is this actually a software problem
The UK government guidance cited above governs UK public sector procurement. It is referenced here for the underlying buying practice, which applies broadly, not as a rule binding private buyers in the UAE.
