Guide

How to Write a Project Brief for a Developer (One They Can Quote From)

By Fahad Tariq, founder of Zirah Tech · Published November 3, 2026

Send the same vague idea to five developers and you can get five very different prices. A good project brief for a developer fixes that. It is one to three pages that say what you need, what you do not, and what you are still guessing.

Quotes differ because developers price their own guesses

When a brief is thin, each team fills the gaps with its own assumptions and prices the risk of being wrong. Some add a large contingency. Others quote low on a narrow reading and recover the difference through change requests. (High Digital)

One agency reports estimates that differ by a factor of five, sometimes ten, for the same vague description. (Workbox) The gap is mostly interpretation, not skill or hourly rate.

Start with the problem and one measurable outcome

Write one paragraph on the business problem and one outcome you can measure. "Cut proposal turnaround from five days to one" gives a team something to design towards. "Build a proposal tool" does not. (High Digital)

"We want a modern app" is not a goal. "We want customers to book online instead of by phone" is.

Say who uses it, on which devices, and in which roles. Avoid prescribing technology unless something real forces it, such as an existing platform or hosting contract.

Describe one full journey, including what goes wrong

Pick the main thing a user does and walk through it: a customer places an order, staff approve it, stock is reserved, the customer gets an update. Then add the failure cases: information is missing, the request is rejected, payment fails. (Corexia)

Failure cases are where hidden work lives, and buyers rarely mention them. (Workbox)

Keep the scope to a task a user would recognize. GOV.UK's service guidance warns that a scope that is too broad hides what problem it solves, and one that is too narrow leaves the user without the outcome they need. (GOV.UK Service Manual)

Split must-haves from later, and write what is out of scope

Mark each requirement as essential for launch, useful later or uncertain. A clear must-have list lets a developer price a realistic first release. (Corexia, High Digital)

Then write the exclusions. Say what is not included this time: a native mobile app, data migration, translation, admin reporting. Quiet exclusions are one reason a quote comes in low. Testing, deployment, documentation and post-launch fixes can be left out of a cheap quote and billed later. (Workbox)

Describe each must-have as something someone can check. "Easy dashboard" leaves the developer to guess. "A dispatcher can see unassigned requests and assign one without opening each record" is testable. (ShultzPrime)

List every integration, existing system and piece of data

Name every system the product must connect to: payments, accounting, CRM, email, maps, your current site. Business language is fine. Note where data lives and how clean it is. Integrations and messy data are among the most frequent causes of budget overruns. (High Digital)

Never put passwords or private customer exports in the brief. It may go to several providers. Give access later through user roles you can remove. (SI Experts, Corexia)

Share a budget range, a real deadline and one approver

Give a range. It feels like giving away your negotiating position, but it lets a developer propose the best fit instead of guessing. (High Digital) Without one, you tend to get unrealistic quotes, or quotes from teams that cut corners to win. (TheCodeVolt)

Give a launch date and say whether it is hard (a campaign, a season) or a preference.

Name one person who approves work and how fast they reply. Approvals that take two weeks are a common reason projects slip. (TheCodeVolt) Five people giving feedback in five chats is another. (SI Experts)

Label what you know and what you are guessing

The ShultzPrime template suggests tagging important statements with one word. (ShultzPrime)

Where you do not know, write "unknown" and name who will find out. A blank field could mean "none", "unknown" or "forgotten". (ShultzPrime)

A one-page template you can copy

1. Project name, owner, and the decision this brief supports
2. Problem and one measurable outcome
3. Users, roles, devices, language
4. Main journey, plus what happens when it fails
5. Must-have features, written as things someone can check
6. Later ideas
7. Out of scope (and what would bring it back)
8. Existing systems, files, test access (no passwords)
9. Integrations and where data lives
10. Examples you like and dislike, one line each on why
11. Budget range
12. Launch date, why it matters, and who approves work
13. Facts, assumptions, open questions (labeled)
14. Please return with your quote: your assumptions,
    exclusions, and questions that would change the price

Before sending, ask someone outside the project to read it. If they cannot say the goal back in one sentence, simplify it. (SI Experts)

A before and after example

This is a made-up example to show the edit, not a client story.

Before: "We need an app for our service business. Modern, customer accounts, some reporting. Budget is flexible. ASAP."

After:

• Outcome: customers book and reschedule online, so the office stops taking most bookings by phone.
• Fact: 3 office staff on laptops; customers mostly on phones.
• Must-have: customer logs in, picks an open slot, gets an email confirmation. Staff see all bookings and can reschedule. A failed payment does not confirm a booking.
• Later: invoices, reviews, SMS reminders.
• Out of scope: native mobile apps, migration from the old calendar.
• Assumption: Stripe card deposits are enough.
• Budget range and date: a lower and upper figure for phase one; live before the spring season; one owner approves within two business days.
• Open question: do staff vacations need to block slots?

Now three developers are pricing roughly the same thing.

Send the same brief to about three people and ask for assumptions back

About three companies is usually enough. Send all of them the same document so the quotes are judged on equal terms. (TheCodeVolt)

Ask each to return assumptions, exclusions and the questions that would change the price. Then you compare outcomes, not totals built around hidden scope. (ShultzPrime, Corexia) If an unknown integration blocks a credible price, a short paid discovery phase can be cheaper than a wrong estimate. (High Digital)

At Zirah Tech, the process starts with a free 30-minute call, then a written proposal with milestones, a timeline and a fixed price or retainer. A rough brief is enough for that call. You can book it here.

Frequently asked questions

How do I write a project brief?

Write the problem and one measurable outcome, list must-haves, mark what is out of scope, name integrations, then add a budget range, a date and one approver. (High Digital, SI Experts)

Should I include my budget?

Usually yes, as a range. It helps the developer propose something that fits. (High Digital, TheCodeVolt)

What is the difference between a brief and a scope of work?

You write the brief before quotes. The developer usually writes the scope of work after reading it. (SI Experts)