How to Brief a Developer So the Quote Doesn't Move

A quote moves when the brief leaves room for different guesses. Brief a developer with the problem, the users, the one workflow that matters, what's out of scope, and how you'll judge success, all on one page. PMI found 47% of unsuccessful projects miss their goals because of poor requirements. If you can't write the brief yet, pay for a short scoping phase first.

Disclosure: I run Ship It Live, a fixed-price design and development service, so I have a stake in this topic. Every number below links to its source; the build stories are from my own products, not client work.

Why do software quotes change after you hire someone?

Because the quote priced one product and you meant another. A vague brief lets every developer imagine a different version, and the price follows the imagination. When the real requirements surface mid-build, the quote moves.

This isn't a rare failure. In PMI's research on requirements management, 47% of unsuccessful projects failed to meet their goals because of inaccurate requirements management. On large IT projects, McKinsey and the University of Oxford found that projects ran 45% over budget on average while delivering 56% less value than predicted, from a study of more than 5,400 projects.

Your first build is far smaller than those, but the mechanism is the same: unclear scope turns into extra work, and extra work turns into extra cost.

What should a brief for a developer include?

A brief answers the questions a developer would otherwise guess at. Keep it to one page:

Section	What to write	Why it stops the quote moving
The problem	Who has it, and what it costs them today	Everything else is judged against this
The users	Each type of user, in a sentence	Every user type adds screens and permissions
The core workflow	The one journey that must work, step by step	It's most of the build, so it must be priced precisely
Must-haves	Features version one can't launch without	Sets the minimum scope
Out of scope	What version one won't do, written down	The most important list: it stops scope creep
Integrations	Payments, email, existing tools	Each one is real work
Platforms	Web, iOS, Android	Each one changes the build
Constraints	Deadline, budget range, must-use tech	Lets the developer say early if it won't fit
Success	How you'll know it worked after launch	Keeps decisions tied to the goal

Write the out-of-scope list as carefully as the feature list. Most quote changes are features nobody said were out.

Can I use a one-page brief template?

Yes. Copy this, fill it in, and send it to anyone quoting:

• Product, in one sentence: what it does and for whom.
• The problem today: how people solve it now and what that costs them.
• Users: each type of user and what they need to do.
• The core workflow: numbered steps for the one journey that must work.
• Must-haves for version one: a short list.
• Not in version one: a short list, written as clearly as the must-haves.
• Integrations: payments, email, calendars, existing systems.
• Platforms: web, iOS, Android.
• Deadline and budget range: the real ones.
• Examples: two or three products you like, and what specifically you like about each.
• Success after launch: the first number you'll watch.

If design is the bigger question, our guide on how to write a design brief covers the visual side.

What are the most common brief mistakes?

Most briefs fail in the same handful of ways:

• Describing the solution instead of the problem. "We need an app with a dashboard" says less than "our managers spend Monday mornings building a report by hand".
• Listing features with no priority. If everything is a must-have, the developer has to guess what can wait.
• Leaving out the boring parts: password reset, account deletion, admin screens, failed payments. They're real work and they're always needed.
• No out-of-scope list, so every later idea looks like it was always included.
• Hiding the budget. A range lets a developer propose the right version for the money, instead of guessing.
• Copying a competitor wholesale. A reference is useful; "build Airbnb but for dogs" isn't a brief.

Fixing these takes an hour and can save weeks of renegotiation later.

How do I compare quotes fairly?

Send everyone the same brief, then check the quotes cover the same list. A quote that's half the price of the others usually prices half the product.

Ask each developer four questions:

1. What exactly is included, feature by feature?
2. What's not included that you think I'll need?
3. What happens when I want to change something mid-build?
4. Is this a fixed price or an estimate?

The answer to question two is the most revealing. A good developer will point out what your brief missed, such as password reset, admin screens or failed-payment handling, before it becomes a change order. For more on how billing models shift the risk, see fixed price vs hourly software development.

What if I can't write the brief yet?

Then pay for the scoping on its own before you pay for the build. Writing a brief needs decisions about users, workflow and scope, and some founders reasonably need help making them.

Our five-day product discovery sprint is a fixed $700:

Day	Stage	What happens
1	Session one	What the product is for, who it's for, and what must be true for it to be worth building
2–3	Scope and flows	Version one written down, the three journeys that matter drawn out, the cut list kept visible
4	Session two	We go through the scope together and argue about the cut list
5	Plan and quote	A build plan, the risks named, and a fixed quote

Everything is yours whether or not you build with us, and the $700 comes off the build if you book it within 30 days. You leave with the brief this article describes, plus a fixed price for it.

Sources checked on 8 October 2026: PMI, "Requirements Management: A Core Competency for Project and Program Success" (Pulse of the Profession); McKinsey and the University of Oxford, "Delivering large-scale IT projects on time, on budget, and on value". Questions? Talk to the Ship It Live team.