How to write a web project brief that gets an accurate quote

A project brief earns an accurate quote when it answers four things plainly: the one task the software has to perform, the people who will perform it, the systems it must talk to, and the date it has to be live. Put those on paper and most studios can price the work with confidence. Leave them out and every number you receive is a guess in a nice font.

Why the same project gets three very different quotes

When three studios read the same two-paragraph email and come back with three unrelated proposals, it is rarely because they disagree about the work. It is because each one filled the gaps differently. One assumed your payment provider has a sandbox. One assumed you will supply finished copy. One assumed a single round of revisions on every screen. None of those assumptions is wrong, and all of them change the shape of the build.

The useful move is to close the gaps you can close and flag the ones you cannot. A brief that says "we do not yet know whether our CRM allows outbound webhooks" is far more valuable than one that stays silent on the CRM entirely. Silence gets priced as risk. A named unknown gets priced as a short discovery task.

A brief is not a specification. It is a list of the decisions you have already made, so nobody has to price the ones you have not.

Lead with one core task, not a feature list

Most weak briefs are feature inventories: a portal, a dashboard, a booking form, notifications, reporting. That tells a developer what to build but not what matters, so nothing can be traded off. Instead, write one sentence in this shape:

A [role] needs to [do one thing] so that [outcome], without [the current friction].

For example: a regional service coordinator needs to assign a technician to a job from her phone so that the customer gets a confirmed window the same morning, without phoning dispatch. That single sentence tells a studio the primary device, the time pressure, the data the screen must show, and the process being replaced. Every feature on your list can now be sorted against it.

Then describe the audiences. Usually there are three: the people who perform the core task daily, the people who consume the output occasionally, and the administrators who configure things. Say roughly how each group works. "Coordinators in the field, on Android phones, often with poor signal" is a design constraint with a price. "Our staff" is not. Describe volume qualitatively if you do not have numbers: a handful of records a week reads very differently from constant traffic all day.

Name every system it has to touch

Integrations are the single largest source of quote variance, because the cost lives in the other system, not yours. For each one, write four things: the product name, the direction data flows, who owns the account, and whether API access is included on your current plan or licence. That last point catches a surprising number of projects late, when a connector turns out to sit behind a tier the client does not hold.

Flag anything that has no documented API, anything with a vendor who must approve access, and anything with a sandbox you have not tested. If your data currently lives in spreadsheets, say how many, who maintains them, and whether the columns are consistent. Migration of messy data is real work, and it is far cheaper to plan for than to discover. If your project is mainly about connecting systems that already exist, that shapes the whole engagement, and it is worth saying so before anyone estimates screens. Our notes on web app development describe how that kind of work is usually staged.

Content and brand assets: the quiet delay

Builds rarely stall on code. They stall waiting for copy, photography and a logo in a usable format. Answer these before you send the brief out:

• Who writes the words, and are they written yet? Existing copy that needs editing is a different job from copy that does not exist.
• Do you have photography you own the rights to, or will stock imagery do?
• Is there a brand guide, and do you have vector logo files and licensed fonts?
• Do you need English and French, and if so, who provides and approves the translations?
• Does the current site have URLs that must keep working, and does anyone hold the list?

Accessibility belongs here too. Public sector and association buyers usually name a required conformance level, and some private clients do as well. If a level applies to you, say which one in the brief rather than in a review three weeks before launch. It affects colour choices, form design, media captions and the testing budget, and it is far cheaper built in than retrofitted.

Compliance, timing and who signs off

Constraints are not obstacles to hide from a studio. They are the cheapest information you can give one. State any rules on where data may be stored, any sector requirements you operate under, any privacy or records obligations, and any security review or procurement process the project must pass. If a client of yours audits vendors, mention it. If you already know your security and compliance requirements, attach them.

Then be honest about timing. There is a difference between a date tied to something real, such as a conference, a funding period or a seasonal peak, and a date that simply feels good. Say which one you have. A fixed external date changes sequencing and scope; a soft date usually saves money.

Finally, name people. Who is the decision-maker with authority to approve scope? Who reviews, and how quickly can they? A weekly review slot in a calendar is worth more than a paragraph of enthusiasm. Here is what the difference between a vague brief and a priceable one looks like, section by section, using an invented project as an example:

The brief skeleton you can paste today

Open a blank document and answer these in order. Short answers are fine, and "unknown" is an acceptable answer as long as it is written down.

1. One core task. The single sentence described above.
2. Why now. What changed in the business that made this project necessary this quarter.
3. Audiences. Each group, its size, its device, and how often it appears.
4. Must-have outcomes. The handful of things that must be true at launch.
5. Explicitly out of scope. The things you are deliberately deferring.
6. Integrations. Product, data direction, account owner, API access confirmed or not.
7. Existing systems and data. What is being replaced, and where the current data lives.
8. Content readiness. Who writes, what exists, what needs translation.
9. Brand assets. Guide, logos, fonts, photography, and who holds the licences.
10. Compliance constraints. Privacy, residency, accessibility, sector rules, procurement steps.
11. Timing. The target date and the real reason behind it.
12. People. Decision-maker, reviewers, review cadence, and who owns the accounts and domains.
13. Open questions. Everything you want the studio to help you decide.

Two pages is plenty. If a section runs long, it is usually a sign that it contains a decision nobody has made yet, which is exactly the thing worth discussing on the first call.

How OlDevs helps, and what to send us

OlDevs has been building web, mobile and full-stack software from Vancouver since 2014, and we read a lot of briefs. When yours arrives we come back with our assumptions written down, the questions that would change the shape of the work, and a plan you can compare against anyone else's. If sections are still blank, we will help you fill them rather than quietly pricing around them.

Once work starts you get one accountable team, a working demo every week so progress is visible rather than described, and full ownership of all code, designs, accounts and intellectual property. Accessibility to WCAG 2.2 AA is part of the build, not an add-on, and we work in English and French. You can see the shape of an engagement in how we work.

Send us your brief, however finished it is, and we will tell you what we would need to know next. Request a quote and we will reply within one business day.