Why a two-sentence brief gets you a bad quote
Most enquiries we get are a couple of sentences long. "We need a new website, something modern, can you send a quote?" It's a fair question from a busy person. It's also very hard to answer.
A studio reading that has two choices. It can guess, and the guess will be too low to be true or too high to win the work. Or it can cover itself by padding the number for everything it doesn't know yet. So you end up with three quotes for three different things, and the cheapest one usually comes from whoever understood you least.
You don't need a forty-page requirements document to fix this. One page, written by you, answering the questions a developer has to ask anyway. It takes about an hour. We've watched that hour save weeks of emails, and it means the quotes you get back can be put side by side.
The one page, section by section
Use these as headings. A few sentences under each is enough. If a section doesn't apply to you, say so, because a blank reads as an unknown and unknowns get priced in.
- The problem. What's going wrong in the business right now, in plain terms. Not "we need a website" but "we get twenty phone enquiries a week and half of them are for services we don't offer, because the site doesn't explain what we do." This is the most useful thing you can write. It also lets the developer suggest something cheaper than what you had in mind.
- Who it's for. Customers, staff, suppliers. What device they're on, how comfortable they are with technology, what they're trying to get done. A booking tool for a plumber on a phone in a ute is a different build from the same tool at an office desk.
- What success looks like. How you'll know it worked six months after launch. More qualified enquiries, fewer support calls, a process that takes ten minutes instead of two hours. Put a number on it if you have one.
- What exists today. The current site, the spreadsheet, the off-the-shelf tool, the manual process. Who built it, whether you have the logins, and whether any data has to come across. Migrations and integrations are where budgets double, so this section moves the price more than any other.
- Must-haves and nice-to-haves. Two short lists. Must-haves are the things without which the project has failed. Nice-to-haves are everything else, roughly in order. Be strict here. If everything is a must-have, everything gets priced as one and you can't trim later.
- Constraints. A budget range, even a wide one. A deadline, and whether it's a hard date or a preference. The systems you're stuck with: the accounting package, the CRM, the payment provider, the hosting your IT partner insists on. None of this is embarrassing to share.
- Who decides. The person who signs off, the people who need to be consulted, and how fast decisions get made. One decisive owner and a committee of five are very different projects.
- What's out of scope. The things you are deliberately not doing this time. The mobile app that can wait, the second language, the customer portal for phase two. Writing these down stops the quote absorbing them, and stops your own team assuming they're included.
That's the whole document.
What each section does to the price
The problem and the success measure tell us whether you need the thing you asked for. People ask us for a custom web application when an off-the-shelf tool and a small integration would do the job for a fraction of the money. People also ask for a brochure site when the thing that's broken is their sales process. We can't spot either from "we need a website".
Who it's for shapes the design and the testing. Your own staff can be trained on a tool. The public can't, so a public-facing tool has to explain itself, and that costs more to get right.
What exists today is where the risk lives. Old data in an odd format, a CRM that's awkward to connect to, a site nobody has the login for. Any of these can turn a six-week job into a twelve-week one. If a studio knows about them up front it will quote for them. If it doesn't, it either underquotes and sends you variations later, or overquotes to cover itself.
The must-have list gives the studio room to fit your budget without guessing what you care about. Constraints stop us proposing something you can't use. Put together, every section takes away a reason for a developer to pad the number.
A bad brief and a good one
A bad brief reads like this. "We want a new website like the one our competitor has, but better. It needs to look modern and professional, work on mobile, have a contact form and a blog, and integrate with our systems. We'd like it done as soon as possible. Please send pricing."
Nothing in there is wrong. None of it is usable either. "Like our competitor" describes a solution rather than a problem. "Integrate with our systems" could mean a newsletter sign-up or a two-way sync with a twenty-year-old ERP. The quotes that come back will be all over the place.
A good brief for the same business might go like this. The company sells and installs commercial kitchen equipment across Victoria. The current site was built on a template in 2017. It gets enquiries, but most are from home cooks the business can't serve, and the sales team spends hours a week filtering them out. Success is more enquiries from commercial buyers and fewer from everyone else. The site must present the commercial range clearly, capture enough detail for sales to qualify a lead, and push those leads into the existing CRM. A catalogue with pricing would be nice but can wait. The budget is a range, the deadline is a trade show in five months, and the operations manager makes the calls with the owner signing off.
That's only a little longer. But a studio reading it knows what to build, what to leave out, what to connect to and when it has to be done. The quotes will be tighter, and you'll be able to compare them.
What to leave out
The most common mistake is a solution dressed up as a requirement. "We need a React site with a headless CMS" is a set of technical decisions. Unless you have a specific reason for each one, leave them to the developer. Describe the outcome and let the studio propose how to get there. If you don't like what they propose, ask why they chose it. That conversation is worth more than a requirement that rules out the right answer before anyone's looked.
The second is a feature list copied from a competitor. They have live chat, a configurator, a members area and a careers page, so you want them too. Each one costs money to build and to keep running, and most are on their site because someone asked for them once. Start from your problem.
The third is false precision. Give a budget as one exact figure and you'll get a quote for exactly that figure. Call a deadline immovable when it isn't and the studio will compress the plan and charge you for the compression. Ranges get you straighter answers.
What happens to the brief
A brief starts a conversation. Any studio worth hiring will read it, come back with questions and push on a few of your assumptions. For anything bigger than a simple site, it then feeds a discovery phase, where these sections turn into agreed scope, technical decisions and a costed plan.
Writing it also forces the conversations inside your business that otherwise happen mid-project. What is this for, who owns it, what are we not doing. Those are cheaper to have before a developer is on the clock.
We've built websites, custom web applications and mobile apps for Melbourne businesses since 2018, and the projects that ran smoothest nearly all started with a page like this one. If you have something in mind, send us your brief, or even just the problem section, and get in touch. We'll tell you straight what it needs.
