Guide

How to write a project brief a developer can actually quote on.

A good brief is not long or technical. It is a short, honest description of what you want to change, for whom and within what limits. It is the cheapest way to get better questions, sharper proposals and quotes that can be compared with each other.

Key takeaways

Describe the problem and the outcome, not the technology.
One page is usually enough. Clear beats long.
Say what the first release must do and what can wait.
List the systems, people and rules the project has to live with.
Send the same brief to every supplier so quotes can be compared.

Why a brief changes the quotes you get

A supplier who receives “we need an app for our shop” has to guess at everything. Each guess is priced in, some high and some low, so the quotes you receive will be far apart for reasons that have nothing to do with their quality. A brief removes the guessing. Suppliers can then spend their time on the questions that matter, and you can see which of them understood the problem. Our guide on what apps and websites cost shows how scope drives the price.

What to put in it

The goal. Finish the sentence “Customers should be able to … so that …”. A goal such as “book without phoning us” is easier to design for than “we need an app”.
The people. Who will use it, who approves decisions and who will support it afterwards. Note which languages they read.
The first release. Two or three things it must do on day one. Put everything else on a “later” list. See planning a first release.
What already exists. Websites, spreadsheets, accounting or booking tools, social accounts, branding, and any content that must be reused.
Constraints. A deadline and what is behind it, rules that apply (for example privacy and marketing consent), accessibility needs and approvals needed inside your company.
How you will know it worked. Something that would be measurably different, such as fewer phone calls, faster quotes or more repeat bookings.
Budget, if you have one. A range is fine. It lets a supplier propose something that fits rather than something you cannot afford.

Mistakes that lead to vague quotes

Describing a solution instead of a problem. “An app like X” tells a developer very little about your business.
Everything is a priority. If nothing can wait, the supplier must price the largest possible version.
Leaving out the awkward parts. Old systems, difficult stakeholders and tight deadlines are cheaper to plan for than to discover.
Sending different information to different suppliers. You then compare answers to different questions.
Hiding the budget. You may attract only the highest offers, or none you can afford.

A short example

(An illustrative example, not a client.) A small physiotherapy practice writes:

Goal: patients can book and reschedule a treatment without phoning, so that the front desk stops spending mornings on the telephone.
People: patients (English and Chinese), four therapists and one receptionist.
First release: online booking against each therapist's real availability, a reminder with a reschedule link, one calendar for the front desk.
Later: packages, online payment, intake forms.
Existing: a paper diary, a shared spreadsheet of patients and a clinical record system that must stay as it is.
Constraints: health information must be handled carefully; no sensitive details in messages; launch before January.
Success: half as many booking calls and fewer empty slots within three months.

Any supplier can respond to that with specific questions and a scoped proposal.

Let a tool do the first draft

Our project brief builder asks the questions above in order and assembles the answers into a brief you can edit, copy or send to any supplier. It runs in your browser and stores nothing unless you choose to share it.

Frequently asked questions

How long should a brief be?

One page is usually enough, and two is plenty. If it takes much longer than that, you are probably describing the solution rather than the problem. Detail can follow in conversation.

Should I include screenshots or examples of other products?

Yes, as illustrations of what you like and dislike, with a sentence on why. They help, provided the brief explains your goal; otherwise suppliers may simply copy.

Is it safe to share a brief with several suppliers?

Generally, yes, if it contains no confidential material. Leave out passwords, customer data and anything you would not want a competitor to read. Where something is sensitive, ask for a confidentiality agreement first.

Have a brief, or the start of one?

Send what you have, even a few sentences. We will reply with questions and, where it fits, a proposed first scope.

Request a project quote