Why the brief decides the quote
A studio quoting your project is estimating hours. Where your brief is clear, the estimate is close. Where it is vague, the studio has to guess, and each one guesses differently: one assumes the simplest version to keep the number low, another assumes the most complex to protect itself. You end up comparing guesses rather than prices.
A good brief removes the guesses. It does not need to be long, and it should not try to design the software. It needs to describe who will use it, what they need to do, what it connects to, what data it holds and what constraints it lives under. Those answers decide most of the hours, and so most of the quote.
What a good brief contains
- 01
The problem, in a paragraph
What is going wrong today, for whom, and what it costs you in time, errors or lost business. This is what lets a studio suggest a simpler answer if there is one.
- 02
The users
Every type of person who will use it: customers, staff, managers, administrators, partners. For each, the three to five things they must be able to do.
- 03
The screens
A rough list of pages or screens. It does not need to be right; it needs to exist. Screens are the clearest unit of size there is.
- 04
The integrations
Every system it must talk to: accounting, CRM, ERP, payment provider, email, single sign-on, a partner's API. Name the product and version if you know them.
- 05
The data
What it stores, roughly how much, whether any of it is personal or regulated, and whether existing data has to be moved in from an old system.
- 06
The platforms
Web only, or iOS and Android apps too. Which browsers and devices matter. Whether it must work offline.
- 07
The constraints
Deadlines that are real (a launch event, a regulation date) and ones that are only preferences. Hosting requirements, such as data kept in Canada. Accessibility and language requirements.
- 08
What already exists
Designs, a brand guide, an old system, a prototype, documentation. Each one can save work, or create it.
- 09
After launch
Who will run it, who will support users, and whether you want a support plan or your own team to take over.
- 10
A budget range
It feels like a negotiating risk, but it is the fastest way to learn whether your idea fits, and what to cut if it does not. A good studio will tell you what is realistic within it.
Count screens and users, not features
Feature lists are where briefs go wrong. "User management" can mean a sign-in page or a full system of roles, invitations, approvals and audit logs. A list of users and screens is harder to misread, because each screen has to be designed, built and tested, and each user type adds permissions to every one of them.
| Who | Screens they use |
|---|---|
| Customer | Sign up, sign in, browse services, book a time, pay, my bookings, cancel or reschedule, profile |
| Staff | Today's schedule, booking details, mark attended, notes on a customer |
| Manager | Staff calendar, services and prices, opening hours, reports |
| Administrator | Users and roles, settings, payment provider, email templates |
Twenty-odd screens and four user types, written in five minutes, tell a studio more than three pages of feature descriptions. If you are unsure whether something is one screen or two, say so; that is a good question for the first call.
Name every integration and every source of data
Integrations are where estimates go wrong most often, because the other system is outside everyone's control. Its documentation may be out of date, its test environment may not exist, and its limits may only appear under real use. A brief that names every integration lets a studio check each one before quoting, rather than discovering it in month two.
- Name the product: "QuickBooks Online" rather than "our accounting software".
- Say which direction the data flows: read only, write only, or both, and how often.
- Say whether you have API access already, or who would need to grant it.
- Mention any data migration from an old system, with a rough number of records and how clean you believe they are.
State the constraints plainly
Constraints change the work more than most features do, so put them in writing even when they feel obvious.
- Accessibility: if the software is public, say which level you need. The W3C's accessibility guidelines define levels A, AA and AAA [1], and naming one turns a vague wish into a requirement that can be quoted and tested.
- Privacy: if it holds personal information, say so. Canada's PIPEDA rests on fair information principles such as consent, limiting collection, safeguards and individual access [2]. Your advisers can tell you what applies; the studio needs to know it applies.
- Regulated data: health, financial or government data carry their own rules. Mention them in the first conversation, not after the quote.
- Hosting: whether data must stay in Canada, whether you have a preferred cloud provider, or whether it must run on your own servers.
- Languages: English and French from day one is a different project from English now and French later.
- Deadlines: which dates are fixed, and why.
What to leave out
A brief is not a design or a technical specification, and trying to write one usually backfires.
- Leave out the technology, unless it is a real constraint (your team already runs a certain stack, or a regulator requires a certain host). Let the studio propose and explain its choice.
- Leave out detailed screen designs unless you already have them. A sketch of an important screen helps; a pixel-perfect mock-up of every screen locks in decisions before anyone has tested them.
- Leave out features you are not sure about, or list them separately as "later". A quote padded with maybes is harder to compare.
- Leave out confidential details you do not need to share yet. A studio can quote from the shape of the problem; it does not need customer names or financial results.
A brief, turned into an estimate
The booking portal in the table above, with a web app, iOS and Android apps, card payments, a connection to the client's accounting system, English and French, and personal information, looks like this in our estimator. The worked example below shows the range from our rate card today, with the hours by role and the payment schedule.
Worked example, priced now
A booking portal from a one-page brief
About twenty screens across web, iOS and Android for customers, staff, managers and administrators, with payments, an accounting integration, notifications, and English and French.
- Build
- ≈ US$99,100 to US$152,000, delivered within 27 weeksCAD 141,100 to 215,800
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
Estimated effort by role
- Development
- 539 to 824 h
- Product designer
- 101 to 154 h
- Project manager
- 75 to 115 h
- Senior product designer
- 67 to 103 h
- Senior backend developer
- 67 to 102 h
- QA engineer
- 63 to 97 h
- Backend developer
- 62 to 95 h
- Frontend developer
- 61 to 94 h
- Senior engineer
- 40 to 62 h
- Senior frontend developer
- 37 to 56 h
- Software architect
- 36 to 55 h
- Mobile developer
- 34 to 52 h
- Junior backend developer
- 31 to 47 h
- Senior mobile developer
- 27 to 41 h
- Junior frontend developer
- 25 to 38 h
- Junior mobile developer
- 15 to 23 h
- DevOps engineer
- 13 to 20 h
- Technical writer
- 11 to 17 h
How it is paid
- Deposit 20%
- CAD 28,220 to 43,160
- Discovery 9.2%
- CAD 12,981.20 to 19,853.60
- Design approved 9.2%
- CAD 12,981.20 to 19,853.60
- Core features 7.6%
- CAD 10,723.60 to 16,400.80
- Full build 5%
- CAD 7,055 to 10,790
- First build on devices 20.1%
- CAD 28,361.10 to 43,375.80
- Testing and fixes 2.5%
- CAD 3,527.50 to 5,395.00
- Store submission 6.7%
- CAD 9,453.70 to 14,458.60
- Launch 9.7%
- CAD 13,686.70 to 20,932.60
- Holdback, 30 days after launch (10%)
- CAD 14,110 to 21,580
Open it in the estimator and change one answer at a time: drop the mobile apps, add real-time updates, switch to a clean standard design. Watching the range move is the quickest way to see which parts of your own brief matter most.
Sending the same brief to several studios
Getting more than one quote is sensible, and a written brief is what makes them comparable. Send every studio the same document, answer every studio's questions in writing, and share each answer with all of them. Otherwise the studio that asked the best question gets the most accurate picture, and its quote looks worse for being honest.
- Ask each studio to list the assumptions behind its number, and compare those before the totals.
- Ask for the hours by role, so you can see whether testing, design and project management are included.
- Ask what is excluded: hosting, support, third-party fees, content and data migration.
- Be wary of a quote far below the others. It usually means part of the brief was read differently, or left out.
A one-page template
- Project name and one sentence on what it is.
- The problem today, in a paragraph.
- Users: each type, with the three to five things they must do.
- Screens: a rough list, grouped by user.
- Integrations: each system, the direction of data, and whether access exists.
- Data: what is stored, whether it is personal or regulated, and any migration.
- Platforms: web, iOS, Android, offline.
- Constraints: deadlines, hosting, accessibility, languages, compliance.
- What exists: designs, brand, old systems, documents.
- After launch: who runs it and who supports it.
- Budget range, and what matters most if it has to give.
What happens after you send it
- 01
Questions
We read the brief and come back with the questions it raises, usually about integrations, data and user roles.
- 02
An estimate with its assumptions
You get a range, the hours by role and the list of assumptions it rests on, so you can see exactly what was priced.
- 03
Discovery
If you go ahead, the first stage confirms the screens, integrations and data in detail, and the range narrows to a fixed price for the build.
- 04
Changes, priced before work
Anything that changes after that is written up as a change order and approved before any work on it starts.