How to write a project brief that gets an accurate quote

A quote is only as accurate as the brief. “We need an app” produces a range, or a number the developer will have to reopen. The brief below is what we ask for on a scoping call. You can send it before the call and save half the hour.

Users

Who logs in, and who must not see the same things. “Everyone” is not a role. Two roles with different screens is a different product from one admin login.

The job

Three actions those users must complete. Not a feature list copied from a competitor. If you cannot name three, you are not ready for a fixed price. You are ready for an hourly discovery slice, which is a legitimate quote — just a different one.

What already exists

A repository, a spreadsheet, a Shopify store, nothing. Link it if you can share it. An existing codebase changes the price more than the adjective you put in front of “modern.”

Constraints

The date that is real, the systems that must be integrated, and the things legal or brand will not allow. A date you invented to sound serious wastes a week. A date tied to a launch or a contract is useful.

Out of scope

Write one paragraph of what this phase will not do. This is the highest-leverage section. It is also the one people skip because it feels negative. It is how fixed prices survive.

Success

How you will know the phase worked, in a way we can demo. “Users love it” is not demoable. “A manager can export last month’s orders” is.

What you do not need to send

A 40-page specification, a choice of framework, or a budget you are unwilling to say. Budget helps — even a range — because it tells us whether to scope a first slice. Hiding it does not get you a lower price. It gets you a quote for a product you will not buy.

If you want a template to fill in, use the project brief download and send it with the quote form. We reply with a fixed price or with the questions that are blocking one.