Short answer: a brief that gets you accurate, comparable quotes covers ten things: background, users, the core job, prioritized features, platforms, integrations and data, constraints, budget range, timeline, and how you will choose. Describe problems and outcomes, rank everything, state your budget, and mark what you have not decided. The template below can be copied as it is.
What a team needs in order to quote accurately
Every quote is an effort estimate multiplied by a rate, plus a margin for what the estimator does not know. You cannot change the rate, but you control most of the unknowns. The items below are the ones that move an estimate the most, in rough order of impact.
| What the estimator needs to know | Why it changes the number |
|---|---|
| How many kinds of user there are, and what each one does | Each role with its own interface can add 30–60% to the core work |
| Which platforms are needed at launch | Web only, one mobile codebase, or both is the largest single cost decision |
| Which features are must-have and which can wait | Without priorities the team prices everything, and you cannot cut sensibly later |
| What the product connects to | Each integration is days to weeks, depending on the quality of the other system's API |
| Whether money moves through the product | Payments, payouts, refunds and tax handling each add effort and review time |
| What kind of data is stored | Health, financial or children's data brings legal duties and extra engineering |
| What already exists | Designs, a prototype, a codebase or a brand can save weeks, or cost weeks if they have to be reworked |
| Who decides, and how fast | A single decision-maker who answers within a day shortens every project |
Anything missing from that list gets filled with an assumption. Cautious teams assume the expensive version and quote high. Less careful teams assume the cheap version, quote low, and recover the difference through change requests. Neither helps you, which is why a clearer brief usually produces lower and closer quotes. The arithmetic behind those quotes is explained in the guide to estimating MVP cost from effort and rates.
The brief, section by section
1. Background and goal
Two or three paragraphs: who you are, what problem you have seen, why now, and what success looks like in six to twelve months. Use a measurable outcome where you can: "50 paying clinics", "replace the spreadsheet for all 12 dispatchers", "cut quote turnaround from two days to two hours". This paragraph lets the team make hundreds of small decisions in your favor without asking.
2. Users and roles
List each type of user, roughly how many you expect in the first year, what device they use and in what setting. "Warehouse staff on shared Android tablets, wearing gloves" tells a designer more than a persona slide.
3. The core job
Describe the single most important workflow from start to finish in plain steps. If you cannot pick one, the first release is probably too broad. Our guide to scoping and building an MVP has a method for narrowing it.
4. Features, ranked
Sort features into three groups: must have for launch, should have if budget allows, and later. Write each as something a user can do ("a customer can reschedule a booking up to 24 hours before") instead of a component ("calendar module"). Keep the must-have list short enough that you are slightly uncomfortable.
5. Platforms and devices
Web, iOS, Android, or a combination, and which comes first. Mention offline use, tablets, old devices, kiosk mode or accessibility requirements here, since each affects the approach. If you are unsure, say what your users carry and let the team recommend. The trade-offs are covered in native or cross-platform for a first app.
6. Integrations and data
Every outside system the product must talk to: payment provider, accounting, CRM, email and SMS, maps, identity providers, hardware, an existing database. For each, note whether you already have an account and API access. Then describe the data: what personal information is stored, where your users are located, and whether existing data has to be migrated.
7. What already exists
Wireframes, designs, brand guidelines, a no-code prototype, an old codebase, user research, a waitlist. Link to them. If there is existing code you hope to reuse, say so and expect the team to ask for read access before committing to a price.
8. Constraints
Fixed dates (a trade show, a funding milestone, a contract start), regulation, required hosting region, a technology your in-house engineer must be able to maintain, languages, and anything the product must not do.
9. Budget range and timeline
A range, in a named currency, with a note on how firm the top is. A target launch date with a note on whether it is fixed or preferred. If the two conflict with the feature list, a good team will say so in its first reply.
10. How you will decide
Who is evaluating, what you want in the response (line-item scope, exclusions, team, timeline, pricing model), the date you want responses by, and when you will choose. Say how many teams you are approaching. It is a courtesy, and it filters out teams that only respond to exclusive invitations.
Template: copy and adapt
Replace the bracketed text. Delete any line that does not apply, and write "undecided" wherever that is the honest answer.
Using the template. Paste it into a document, fill it in over an hour or two, then ask someone outside the project to read it and explain the product back to you. The places where they hesitate are the places to rewrite.
Project brief: [product name]
Prepared by: [name, role, company, email]. Date: [date]. Version: [1.0]
A. Background and goal
- Company in one sentence: [what you do, for whom]
- The problem: [what is slow, costly, missing or painful today, and for whom]
- Why now: [trigger, opportunity or deadline]
- Success in 6–12 months: [one to three measurable outcomes]
- Stage: [idea / validated with interviews / paying customers on a manual process / replacing an existing system]
B. Users
- Role 1: [name], [expected number in year one], [device and setting], [main thing they need to do]
- Role 2: [as above]
- Internal or admin users: [who manages content, users, payments or support]
C. Core workflow
- [User] does [first step]
- [System or other user] responds with [second step]
- [Continue until the user has the outcome they came for]
D. Features by priority
- Must have for launch: [5–10 capabilities, each written as "a [role] can ..."]
- Should have if budget allows: [list]
- Later, not in this quote: [list, so the team can plan for it without pricing it]
- Explicitly out of scope: [list]
E. Platforms
- Launch platforms: [responsive web / iOS / Android / desktop]
- Special requirements: [offline use, tablets, accessibility level, languages, older devices]
F. Integrations and data
- Systems to connect: [system, purpose, whether you have API access]
- Payments: [none / one-off / subscriptions / marketplace payouts], [preferred provider if any]
- Personal or sensitive data stored: [types], users located in [countries]
- Data to migrate: [source, approximate volume, condition]
G. Existing materials
- [Designs, prototype, brand assets, codebase, research, competitor references, with links]
H. Constraints
- Dates that cannot move: [date and reason]
- Regulatory or contractual requirements: [list, or "none known"]
- Technical constraints: [required stack, hosting region, existing team skills, or "open to recommendation"]
I. Budget and timeline
- Budget range for the first release: [currency, low to high], [firm ceiling / flexible for a good reason]
- Target launch: [date], [fixed / preferred]
- Expected work after launch: [ongoing development / maintenance only / handover to in-house team]
J. Selection process
- Decision-maker and day-to-day contact: [names]
- Please include in your response: [line-item scope, exclusions, assumptions, team, timeline, pricing model, payment schedule]
- Responses by [date]; decision by [date]; approaching [number] teams
- Open questions we would like your view on: [list]
A short filled-in example
The example is invented to show tone and level of detail. It is about one page when pasted into a document.
Project brief: FieldCheck (fictional). Prepared by the operations director of a 40-person property maintenance company.
- Background and goal. Our 22 technicians complete inspection reports on paper. Office staff retype them, which takes about 15 hours a week and delays invoices by three to five days. Goal: reports completed on site, in the customer's inbox the same day, with no retyping. Stage: replacing a manual process; no existing software beyond accounting.
- Users. Technicians (22, company Android phones, often in basements with no signal). Office coordinators (3, desktop browser). Customers receive a PDF by email and do not log in.
- Core workflow. Coordinator assigns a job. Technician opens it, completes a checklist, adds photos and a customer signature. Report syncs when there is signal. Coordinator reviews and sends it.
- Must have. Job list per technician; configurable checklists; photos with notes; signature capture; offline completion with later sync; PDF report; coordinator dashboard with status; user management.
- Should have. Push notification on new job; export of completed jobs to our accounting system.
- Later. Customer portal; route planning; iOS.
- Integrations and data. Accounting export (CSV is acceptable at first). Customer names, addresses and photos of premises; all users and customers in the UK. About 3,000 past customers to import from a spreadsheet.
- Constraints. Must work fully offline. UK or EU hosting preferred. No in-house developers, so we need documentation and a support option.
- Budget and timeline. £35,000–£55,000 for the first release; the top is firm. Pilot with five technicians by March, preferred, not fixed.
- Selection. Approaching four teams. Please send line-item scope, exclusions, assumptions and pricing model by the 14th. Open question: Android app or a web app that works offline?
Notice what it leaves out: no screen descriptions, no technology demands, no feature list copied from a competitor. A team can estimate this, challenge it and propose a cheaper first step.
Mistakes that make quotes worse
Solution-first briefs
"We need a React Native app with a Node backend and a microservices architecture" tells the team what to build and hides why. If the real need is 22 people filling in forms offline, there may be a simpler and cheaper route. Describe the problem, state real constraints, and ask for a recommendation. You also learn more about each team from how they reason than from how they price your predetermined answer.
Hiding the budget
Founders withhold the budget to avoid quotes that expand to fill it. The protection against that is a line-item scope and competing proposals, not secrecy. Without a range you receive proposals for three different products at three different sizes and cannot compare them.
No priorities
A flat list of 40 features, all "essential", forces the team to price all 40. When the total comes back over budget there is no agreed way to cut. Ranking first means the conversation becomes "what fits in the range" instead of "why is it so expensive".
Writing features as nouns
"Messaging", "dashboard" and "reports" can each mean two days or two months. Write what a user can do and what they see afterwards.
Forgetting the back office
Someone has to manage users, fix bad data, issue refunds and answer support requests. If the brief does not mention an admin area, some quotes will include one and some will not.
Hiding the uncertain parts
If you have not decided on the business model or a key integration, say so. Unknowns that surface in week five cost more than unknowns discussed before the quote. A short paid discovery phase is often the right response to a brief with large open questions; how that works with different pricing models for software projects is covered separately.
Sending a different brief to each team
Refining the brief between conversations is natural, but it makes the quotes incomparable. Version it, and send the update to everyone.
What to leave out
- Screen-by-screen descriptions, unless designs already exist. They lock in a solution before anyone has tested it.
- Technology requirements you cannot justify. Keep real constraints; drop preferences borrowed from a blog post.
- Scale fantasies. "Must support ten million users" prices in infrastructure you will not need for years. State realistic first-year numbers.
- The full long-term roadmap in detail. A few lines under "later" is enough for the team to avoid painting you into a corner.
- Confidential material that is not needed for an estimate: customer lists, financial models, proprietary formulas.
- Your pitch deck. Market size does not affect effort.
After you send it
Expect questions. A team that replies with a price and no questions has either not read the brief or is quoting a package. Useful replies challenge a priority, point out a risk you did not mention, or propose a smaller first step. When proposals arrive, compare scopes and exclusions before totals, then work through the due-diligence questions for a development agency with your shortlist. Before signing, check the agreement against the software development contract checklist.
At BBR a brief like the one above is enough to start: the usual next step is a written reply with questions, then a call, then a proposal with scope, approach, timeline and price. The way projects are scoped and delivered is described under custom software development and, for first releases, MVP development.