You email five companies the same two paragraphs. Back come five numbers that are nothing like each other, and you have no way to tell whether the cheap one is a bargain or a trap.
That's not a supplier problem. It's a brief problem. When the brief is vague, every supplier fills the gaps with their own assumptions, and you end up comparing five different projects that happen to share a name.
The fix takes about an hour, and it's worth more than any negotiation you'll do later. Here's what to decide before you contact anyone.
Why vague briefs cost you money
Three things happen when a brief leaves room for interpretation.
- Quotes become incomparable. One supplier assumed you'd write the content, another priced for writing it. One assumed three page designs, another twelve. The numbers differ because the work differs, and you can't see it.
- The cheapest quote usually excluded the most. Not through dishonesty — through optimism. Whatever wasn't specified wasn't priced, and it becomes a variation later, when you have no leverage.
- You lose the ability to say no. Once a project is underway and something obvious turns out not to be included, your only options are to pay for it or do without. Both are worse than having decided at the start.
The eight things to decide first
You don't need a formal document. You need answers to these.
- What is the business problem? Not the solution — the problem. "Our stock count is wrong by the time it's finished" is more useful than "we need inventory software." State the problem and let suppliers argue for their approach. You'll learn more from their reasoning than from their price.
- Who is it for? The actual users. A website for existing customers looks different from one built for cold buyers comparing three suppliers. An internal system serving four people has different requirements from one serving forty.
- What has to be true when it's finished? Three to five outcomes, written plainly. "A customer can order without messaging us." "Stock updates when a sale is made." These become your acceptance criteria — the things you check before final payment.
- What's explicitly out of scope? The most valuable section, and the one nobody writes. Naming what you're not doing now prevents both scope creep and the assumption that it was included. "Not migrating historic data before 2024." "No mobile app in this phase."
- What already exists? Current systems, tools you're keeping, your domain and hosting, brand assets, content. What must be integrated with, and what's being replaced. Suppliers price risk when they can't see the existing environment — and it's worth knowing who actually owns your website and accounts before you list them.
- Who decides? One person who can approve scope and design. Projects slow down most when feedback arrives from a committee, contradicts itself, or comes in three weeks late because nobody owns it.
- What's the real timeline, and why? A date attached to a reason — a season, a lease, an event — is useful. "As soon as possible" tells a supplier nothing and usually means the project will drift.
- What's the budget range? Yes, share it. Withholding budget doesn't get you a better price; it gets you quotes for the wrong project. A range lets a supplier tell you what's achievable within it, or say honestly that it isn't.
The one-page brief
Copy this, fill it in, send the same version to everyone.
Project: [name] Company: [what you do, in one line] The problem. [2–3 sentences. What's not working, and what it costs you in time, money or lost sales.] Who it's for. [The people who'll use it, and what they're trying to do.] What must be true when it's done. [3–5 outcomes, plainly stated.] Out of scope for now. [What you're deliberately not doing in this phase.] What already exists. [Current systems, tools being kept, brand assets, content, domain and hosting.] Who decides. [One name. Who else needs to be consulted, and how quickly they respond.] Timeline. [Target date and the reason behind it.] Budget range. [A range. It's fine to say "we're testing whether this is 20k or 100k."] What we'd like back. [A written scope with inclusions, exclusions, cost and timeline. Not a design.]
That last line matters. Asking for a scope rather than a concept saves everyone unpaid speculative work and tells you far more about how a supplier thinks.
How to compare the quotes you get back
Once you've sent the same brief to everyone, read the responses for these:
- Did they ask questions? A supplier who responds with a number and no questions has either done this exact project before or hasn't thought about yours. Questions are a good sign.
- Is the exclusion list specific? "Excludes content" is generic. "Excludes copywriting for 12 pages; client supplies product photography" is a real answer.
- Does the timeline name your obligations? A supplier who says what they need from you and when is one who has actually planned the work.
- Does the cheapest quote cover the same scope? Line them up against your acceptance criteria. Usually the gap is visible immediately.
- What happens after launch? Support, hosting, updates, and what month two costs. A quote that ends at handover is half a quote.
If you're commissioning a website, what a website costs in Dubai covers what usually sits behind the numbers.
When you can't answer the questions
Sometimes the problem is genuinely unclear — particularly with operations software, where nobody has mapped the process end to end. That's normal, and it's not a reason to write a vague brief and hope.
The alternative is a paid discovery: a short, scoped piece of work that produces the specification. You get a document you can take to any supplier, and you find out what the real project is before committing to it. Ask whether the fee is credited against the build if you continue — it should be.
How we handle briefs
Send us the one-page version above and you'll get a written scope back: what gets built, what stays manual, what it costs, how long it takes. You approve that before anything starts, and changes afterwards are quoted as variations rather than absorbed quietly or sprung on you at the end. That applies whether it's a website, an ERP or an app.
If the brief tells us the project doesn't need what we build, we'll say so. That's a faster conversation for both of us than a quote nobody should accept.
The short version
An hour spent on the brief saves weeks later.
State the problem rather than the solution. Say what must be true at the end. Name what's out of scope. Give a budget range. Send the same document to everyone.
Then judge the replies on the questions they ask, not just the number at the bottom.