Articles · Hiring

2027-02-11 12 min EN / FR

How to brief a developer so you get a useful quote

The quality of a quote depends on the quality of the question. A vague request ("I need a website with a shop") produces vague quotes, wildly different prices and, later, disputes about what was included. A good brief takes an hour or two to write and can save weeks and a lot of money.

You do not need technical vocabulary. You need clarity about your business, your constraints and your priorities.

The goal of a brief

To let a developer answer four questions:

  • What problem are we solving, and for whom?
  • What must exist on day one?
  • What are the constraints?
  • How will we know it worked?

1. Context

Write a few sentences on:

  • Your business: what you do, how big you are, who your customers are
  • The current situation: what exists today (website, spreadsheets, tools) and what hurts
  • The trigger: why now? A deadline, a growth problem, a cost issue, a failure?

Example: "We're a 12-person company selling industrial supplies to professional clients. Orders come by email and phone and are re-entered by hand in our accounting tool. Two people spend about a day a week on this and errors are frequent. We want to cut this down."

2. The problem, not the solution

Describe what you need to achieve before describing how. If you have decided on a solution ("a mobile app"), say so, but also say what problem it should solve, so the developer can challenge it if there is a simpler route.

Useful framing:

  • Who will use it? Staff, customers, partners, and how many of each
  • What will they do with it? The three to five main tasks
  • What's painful today? Where time, money or customers are lost

3. Scope, in priority order

List what you want, then sort it:

  • Must have: the project fails without it
  • Should have: important, but the launch can happen without it
  • Nice to have: only if budget and time allow

This single step lets developers propose a phased plan and price the essential part separately. Quotes become comparable, because everyone is pricing the same core.

Also say what's out of scope, if you know: "no mobile app in this phase", "no migration of data older than 2 years".

4. Existing systems and integrations

Developers need to know what the new thing must connect to:

  • Existing website, ERP, CRM, accounting tool, payment provider, shipping carriers, marketplaces
  • What data flows between them, and in which direction
  • Whether those systems have APIs or are closed
  • Who administers each, and whether the developer will get access

Integrations are one of the biggest hidden costs. Listing them early gives you realistic quotes. When two tools must stay in sync, the failure modes are also worth naming early (see syncing two systems: the five ways it breaks).

Need help turning a messy idea into a brief?

We help you write a clear scope, list integrations, and ask for quotes you can actually compare.

Describe your project Custom solutions

5. Data

  • What data exists today, where, and in what state (clean, duplicated, messy)?
  • How much of it needs to move?
  • Is any of it personal or sensitive data?
  • Who owns data quality on your side?

If you do not know, say so. "We have about 8,000 customers in a spreadsheet with inconsistent formatting" is useful information.

6. Constraints

  • Budget: a range, or at least an order of magnitude. Many clients avoid this, fearing the quote will rise to match. In practice, a range lets the developer propose what fits, and say honestly if it does not. Without it, you get quotes that differ by a factor of ten.
  • Deadline: a real date and the reason for it. "End of November, because of a trade show" is different from "as soon as possible".
  • Technology: only if you have real constraints (existing stack, a required hosting provider, an internal team that must maintain it)
  • Regulation: GDPR, accessibility, sector-specific rules, accounting and invoicing requirements
  • Hosting and ownership: your preferences about where it is hosted and who owns the accounts
  • People: who will be your contact, who validates, how fast can they respond?

7. Success criteria

How will you know the project worked? Pick a few measurable outcomes:

  • "Order entry time drops from a day a week to under an hour"
  • "Customers can place and track an order without calling us"
  • "Month-end closing takes two days instead of five"
  • "The site handles our seasonal peak without slowing down"

These guide decisions during the project, and give you a way to judge it at the end.

8. What you want from the quote

Ask providers to include:

  • A breakdown by phase or feature, not a single number
  • Assumptions made
  • What's excluded
  • Timeline with milestones
  • Who will do the work
  • What you will receive at the end (code, documentation, accounts). The contract clauses worth demanding cover ownership and handover in more detail.
  • Hosting and ongoing costs
  • Maintenance options
  • Payment schedule
  • Their questions and any risks they see

9. How you'll choose

Tell candidates your process: when you will decide, who is involved and what matters most (price, experience, speed, communication). It signals seriousness, and good developers will respond in kind.

A one-page template

PROJECT BRIEF: [Name]

1. Context
   Company, activity, size:
   Current situation:
   Why now:

2. Problem and users
   Who uses it, how many:
   Main tasks:
   Main pains today:

3. Scope
   Must have:
   Should have:
   Nice to have:
   Out of scope:

4. Existing systems and integrations
   System / purpose / data flow / API available?

5. Data
   Sources, volume, quality, sensitivity:

6. Constraints
   Budget range:
   Deadline and reason:
   Technical / hosting / legal constraints:
   Our contact and availability:

7. Success criteria
   (3 to 5 measurable outcomes)

8. Quote format requested
   Breakdown, assumptions, exclusions, timeline,
   deliverables, maintenance, payment terms

9. Selection process
   Deadline for quotes, decision date, criteria

Tips for better responses

  • Offer a short call. A 30-minute conversation often teaches more than ten pages of documents, for both sides.
  • Share examples: sites you like, screenshots of tools you use, a sample spreadsheet.
  • Be honest about uncertainty. "We're not sure whether we need X" invites useful advice.
  • Ask for questions. A developer who has none after reading your brief probably did not read it, or does not see the complexity.
  • Don't send the same brief to twenty providers. Three to five well-chosen candidates are enough, and you can talk to each properly.
  • Consider a paid discovery workshop for larger projects. A short paid scoping phase produces a better specification and a far more reliable quote.
  • When quotes arrive, compare them with the same checklist, not on the headline number alone. See reading a quote: what's missing.

Common mistakes

  • Describing a solution with no problem behind it
  • No budget indication
  • Everything is a priority
  • Forgetting integrations and data migration
  • No named decision-maker
  • A "simple" project that hides complex business rules
  • Comparing quotes that cover different scopes
  • Choosing on price alone
  • Not asking what will be delivered at the end

Checklist

  • Context and trigger explained
  • Problem and users described
  • Scope sorted into must, should, nice, and out of scope
  • Existing systems and integrations listed
  • Data sources and quality described
  • Budget range and real deadline given
  • Success criteria defined
  • Quote format requested
  • Named contact with time to answer questions
  • Three to five candidates, with a short call offered

Related

From a vague request to a brief that works

If you have an idea on paper and want a scope and quote process that protects you, write us.

Start a conversation All articles