How to Write a Project Brief That Gets an Accurate Quote

A quotation is only as accurate as the brief behind it. When a brief is vague, the studio has to guess, and guesses turn into change requests, delays and arguments about what was "included". A clear brief does not need to be long or technical. It needs to answer the questions that change the size of the work.

Start with the outcome, not the feature list

Begin with one or two sentences about what should be different once the product is live. "Customers can book a service visit without calling us" is more useful than "we need a booking module". The outcome tells the team which features matter and which are nice to have.

Describe who will use it

List the people who will open the product and what each of them needs to do. A public website visitor, a staff member who updates prices and a manager who approves orders need different screens and different permissions. If some users work mainly on a phone, say so.

Separate must-haves from later additions

Split your features into two lists:

• Must-have for launch: the things without which the product cannot go live.
• Later additions: useful features that can follow in a second phase.

This single step does more for an accurate price than anything else, because it stops every idea from being priced as part of the first release.

Name the systems it must connect to

Integrations are where hidden work lives. Write down every system the product must talk to: a payment provider, an accounting tool, a CRM, a WhatsApp number, an existing database or a delivery partner. If you know whether the other system has an API, include that too.

Languages, countries and currencies

If the product must work in English and Arabic, or show prices in more than one currency, mention it on day one. Right-to-left layouts, translated content and currency rules affect design, development and testing.

Content: who writes it and when

Text, images, product data and legal pages have to come from somewhere. State whether you will supply them, whether they already exist, and roughly how much there is. Late content is one of the most common reasons a delivery date moves.

Constraints you already know

Include anything fixed: a launch date tied to an event, a budget range, a hosting provider you must use, or a brand guide. Constraints are not a problem; surprises are.

A short template you can copy

• What should change once this is live?
• Who will use it, and on which devices?
• Must-have features for launch
• Later additions
• Systems it must connect to
• Languages, countries and currencies
• Who supplies content, and when
• Dates, budget range and other fixed constraints

Send that, and the quotation you receive can list exactly what is included, what is a later addition and what each part costs.

Discuss a project