The Project Brief That Gets You an Accurate Quote (and the One That Gets You a Guess)

It is a familiar scene. A founder collects three quotes for the same product. One is $8,000. One is $24,000. One is $60,000.

The natural question is which developer is lying. The honest answer was: none of them. They each read the same two-paragraph brief and built three different products in their heads.

The cheap one pictures a form, a list and a login. The expensive one pictures user roles, payments, email notifications, an admin dashboard and a mobile layout for everything. The middle one splits the difference and hopes.

A quote is only as precise as the description it is based on. If you want numbers you can compare, the work starts with the brief.

Why vague briefs produce wild quotes

Every gap in a brief is a decision the developer has to make for you. And each one makes it differently.

Careful developers fill the gaps with the expensive assumption, because underquoting means either eating the cost or coming back to you mid-project for more money. Hungry developers fill them with the cheap assumption, because the lowest number wins the job. Neither is acting in bad faith. They are just guessing in opposite directions.

Same brief, three readings

The spread is in the gaps, not the developers.

• 01

  $8,000

  Form, list, single login. Everything else assumed out.

• 02

  $24,000

  Some roles, basic emails, a simple admin page.

• 03

  $60,000

  Roles, payments, notifications, full admin, every edge case.

The fix is not to write a 40-page specification. It is to close the handful of gaps that move the price the most.

What a useful brief actually contains

1. The problem, in one paragraph

Start with what is broken today, not with features. "Our coordinators spend two hours a day copying orders from email into a spreadsheet, and orders get missed" tells a developer more than "we need an order management system."

The problem statement is what lets a developer push back on a feature that does not serve it. That pushback is often where the savings are.

2. Who uses it, and what each of them can do

List the types of people who will log in. Customers, staff, managers, an admin. For each, write a sentence on what they need to do and what they must not be able to see.

This one section moves quotes more than almost anything else. One type of user with one view is a small product. Four types with different permissions over shared data is a different project, and it is the part founders most often leave implied.

3. The three to five journeys that must work on day one

Write each one as a short sequence: "A customer picks a service, chooses a time, pays a deposit, and gets a confirmation email." Then write what happens on the other side: "The owner sees the booking in a list and can cancel it."

Limit yourself to the journeys the product is useless without. Everything else goes into a separate list called later. A developer can quote the first list precisely and give you rough sizes for the second.

4. The data and the rules

What are the main things the system keeps track of? Orders, clients, appointments, invoices. Roughly how many of them? Are there rules that are easy to forget, like prices that change by customer, stock that must not go negative, or records that can never be deleted?

Business rules are where the time goes. A brief that says "calculate the price" hides a week of work if the price depends on quantity, region, membership and a seasonal discount.

5. Everything it has to talk to

Payments, email, SMS or WhatsApp, an accounting tool, a CRM, a spreadsheet someone still relies on, a login with Google. Each integration is a small project with its own documentation, its own failure modes and its own account that somebody has to own.

If you are not sure yet, list it with a question mark. An integration that appears in week six is one of the most common reasons a fixed quote turns into a change request.

6. What is explicitly out of scope

This is the section almost nobody writes, and it is the one that saves the most money. "No mobile app. No multiple languages. No customer accounts in version one, bookings are by email confirmation only."

Writing it down means every developer quotes the same smaller product, and it gives you a clean list to revisit after launch, when you know what users actually ask for.

7. Constraints: budget, deadline and what already exists

Give a budget range. Founders often hold it back as a negotiating tactic, but it mostly costs them. A range tells a good developer which version of the idea to propose, the lean one or the comfortable one, instead of making them guess and then haggle.

Say whether the deadline is real (a trade show, a contract, a funding milestone) or a preference. And say what already exists: a design, an old system, a domain, data that needs to be imported. Importing ten years of messy records is its own line item.

What to leave out

Technology choices you cannot explain. "Must be built in React with microservices" either reflects a real constraint, like an in-house team that already knows React, or something read in a blog post. If there is a reason, write it. If not, let the developer propose, and judge the reasoning.

A long feature wishlist with no priorities. Twenty features of equal weight tell the developer nothing about what matters, and the quote will price all twenty.

Screenshots of other products as the whole specification. "Like Airbnb, but for boats" is a useful sentence of context. It is not a scope. The parts of Airbnb you do not need are most of Airbnb.

How to read the quotes that come back

A good brief also makes the quotes easier to judge. Look for:

• Assumptions written down. A quote that lists what it assumed is one you can correct. A single number with no breakdown is one you can only accept or reject.
• Questions back to you. The developer who asks about the edge case you forgot has read the brief properly. Silence usually means guessing.
• A first version that is smaller than your list. Someone proposing to cut scope to ship sooner is usually thinking about your money, not theirs.
• Maintenance mentioned at all. Launch is not the last cost. I wrote about what it costs to keep a web application running, and a quote that ignores it is incomplete.

If the quotes are still far apart after a clear brief, ask each developer to walk you through the biggest line item. The difference will be one or two decisions, and now you can make them yourself.

When a brief is not enough

Sometimes you cannot write sections three to five because the answers do not exist yet. You know the problem, but not which workflow is worth automating first, or whether an off-the-shelf tool already covers most of it.

That is a normal place to be, and the honest move is not to force a fixed quote out of it. It is to pay for a short, separate step that turns the problem into a scope: interviews with the people who will use it, a map of the data and integrations, and a first version small enough to estimate properly. It costs a fraction of the build, and it is the difference between a quote and a guess with a currency sign.

Timelines follow the same logic: the clearer the first version, the more reliable every number attached to it.

A one-page template

If you want a starting point, answer these on a single page:

1. What is broken today, and what does it cost you?
2. Who logs in, and what can each of them do and not do?
3. Which three to five journeys must work at launch?
4. What data does it keep, roughly how much, and what rules apply to it?
5. What outside services does it connect to?
6. What is deliberately not in version one?
7. What is the budget range, the deadline, and the reason for the deadline?
8. What already exists that we have to work with?

Send the same page to every developer you talk to. Then you are finally comparing prices for the same thing.

Not sure what the first version should be?

If you have the problem clear but not the scope, a short technical discovery phase is usually the cheapest way to get a brief you can build from and a quote you can trust.

See how a technical discovery engagement works