Most of the briefs that reach us are either a single paragraph (“we need an app that does X, how much?”) or a forty-page requirements document that nobody, including the author, has read all the way through. Neither one can be quoted from, and what happens next depends on the developer. Some reply with a number wide enough to cover any interpretation. Some don’t reply. The good ones ask a lot of questions, which is fine but slow, and it means you’re paying, in time if not in money, for the brief you didn’t write. A brief that a developer can price fits on a page or two, and it’s mostly a matter of knowing which questions they’re going to ask.
Quick answer: A quotable brief says who has the problem and what it costs them now, describes the current process step by step, states what “done” looks like in terms of what people will be able to do, lists the systems it has to talk to, names the constraints (budget range, deadline, hosting, compliance), and says what’s out of scope. A developer can price that in a day. Leave out the budget range and you’ll get a quote designed to survive any budget, which is a bigger number.
Why do vague briefs produce bad quotes?
Because the developer is pricing their own uncertainty. If the brief says “a customer portal”, the honest range is somewhere between a login page that shows invoices and a full self-service system with payments and support tickets, and the difference is a factor of ten. A developer who wants the work will quote toward the top so they don’t lose money, or quote low and make it up in change requests, which is worse for you. One who doesn’t need the work will pass. So the vagueness doesn’t save you anything; it moves the cost into the quote, where you can’t see it.
The forty-page document has the opposite problem. It’s precise about things that don’t matter yet (button colours, field labels) and silent on the things that decide the price (which systems it connects to, how many users, what happens when something goes wrong). It also signals that the author will want every one of those forty pages honoured, which developers price in as friction.
What does a developer need to know?
Who has the problem, and what it costs them. “The ops manager spends four hours a week re-keying orders from email into the accounting system, and about one in fifty gets a wrong quantity.” That one sentence tells a developer the user, the volume, the integration, and roughly what the project is worth to you, which matters because a solution that costs more than the problem is the wrong one.
The current process, step by step, including the workarounds. Where the data comes from, where it goes, who touches it, and what they do when the normal path fails. The workarounds are the important part; they’re where the real requirements hide, and they’re what a developer never finds out about until the second week of the build.
What “done” looks like, as things people can do. “A customer can log in, see their last twelve months of invoices, download any of them as a PDF, and pay an open one by card.” Written that way, a developer can count the screens and the integrations. “A modern, intuitive portal” can’t be counted.
The systems it has to talk to, by name and version. The accounting package, the CRM, the payment provider, the email system, the spreadsheet that is secretly the database. Every integration is a chunk of the price and a chunk of the risk, and a developer will want to know whether each one has an API and whether you have admin access to it.
The constraints. A budget range, a deadline and why it’s the deadline, where it has to be hosted, who owns the code, any compliance requirements, and any technology the business has already committed to. Our post on how much a custom web application costs will give you a sense of where realistic ranges sit.
What’s out of scope. This is the sentence briefs most often lack and the one developers most appreciate. “Phase one does not include the mobile app, the reporting dashboard, or migrating historical data before 2023.”
Why should you share the budget?
Because it’s the single most useful sentence in the brief, and withholding it doesn’t do what people think. The worry is that a developer will quote up to whatever number you give. In practice a range does the opposite: it tells the developer which version of the solution to propose. Told “$15,000 to $25,000”, a good developer will describe what fits in that and what doesn’t, and you’ll learn a lot from where they draw the line. Told nothing, they’ll guess, and the guess will be wide.
If you don’t know the budget, say what the problem costs you a year and let the developer propose something proportionate. That’s a legitimate answer and it produces a better conversation than a number pulled from the air.
What should the brief look like?
Keep it to a page or two, in this order:
- The problem in two or three sentences, with the person who has it and what it costs.
- The current process, as a numbered list of steps, with the workarounds noted.
- What done looks like, as a list of things users will be able to do.
- Users and roles, with rough numbers.
- Systems to integrate with, by name, and whether you have admin access to each.
- Constraints: budget range, deadline, hosting, ownership, compliance, existing technology.
- Out of scope for this phase.
- Anything you already have: designs, an existing system, sample data, a spreadsheet that shows the logic.
Attach screenshots of the current process if there is a system involved; a screenshot of the spreadsheet that runs the business is worth more than a page describing it.
What happens after you send it?
A good developer comes back with questions, and the quality of the questions tells you about the developer. Questions about the workarounds, the edge cases, and what happens when an integration is down mean they’ve built this kind of thing before. A quote with no questions attached to a brief like this is a flag.
Expect a proposal that pushes back on something. If everything you asked for is accepted at the price you hoped, either the brief was unusually good or the developer intends to renegotiate later. Some of our best projects started with the developer suggesting that phase one should be smaller than the brief asked for.
For larger projects, expect to be offered a paid discovery phase before a fixed quote. That’s a week or two of workshops and prototyping that ends in a specification and a firm price, and it’s reasonable for anything that would cost more than a couple of months of work; it’s the alternative to a fixed price that has a large risk premium built in. Whether you then want a freelancer, an agency, or a fractional team depends on how much of this you expect to do again.
If the project is taking over something that already exists, the brief also needs to describe the existing system honestly, including what you don’t know about it. Our developer takeover guide covers what to put in that section, and our post on the signs you’ve outgrown your web developer is worth a read if the reason you’re writing a brief is that the last relationship ended badly.
We’re happy to be sent a brief in this shape; it’s the first step of every custom software project we take on, and we’ll tell you what we’d cut from phase one before we tell you a price.
Frequently asked questions
How long should a brief be?
One to two pages, plus attachments. If it’s longer, the extra pages are usually design detail that belongs in a later conversation. If it’s shorter than a page, it’s probably missing the current process or the integrations.
Should I include a technology preference?
Only if the business has a reason: an existing system to match, in-house skills, or a hosting commitment. Otherwise let the developer propose, and ask them to explain why. A brief that mandates a technology without a reason narrows the field of good developers who’ll respond.
What if I don’t know what’s possible?
Describe the problem and the current process, and stop there. That’s enough for a developer to propose options. Guessing at the solution in the brief tends to anchor everyone on your guess, which is often not the cheapest one.
How many developers should I send it to?
Three is plenty. More than that and you’ll spend longer comparing quotes than the difference between them is worth. Send the same brief to all three so the quotes are comparable.
Should I ask for a fixed price?
For a small, well-defined project, yes. For anything larger, ask for a fixed price for a discovery phase and a range for the build, then fix the build price after discovery. Developers who offer a firm fixed price for a large project from a brief alone are pricing in a lot of risk, and you’re paying for it.
What should I do with the quotes that come back?
Compare what each one includes, not only the totals. A cheaper quote that excludes data migration, testing, or the first month of support isn’t cheaper. Ask each developer what they’d cut to hit the bottom of your range; the answers are more revealing than the numbers.