A quote is an estimate of the project the supplier thinks you described. If your brief is two paragraphs and a competitor link, three agencies will imagine three different projects, and you will compare three numbers that are not about the same thing.
The usual result is one of two disappointments. Either the cheapest quote turns out to exclude half of what you assumed, or change requests arrive in month two and the budget stretches. Both are mostly avoidable. They come from missing information, not from bad faith.
You do not need a forty-page specification. You need a brief that closes the specific gaps that move price and timeline.
Start with the outcome, not the feature list
Begin with what should be true when the project is finished. “Customers can book a site visit without phoning us” is a better opening than “we need a booking module”. The first lets a supplier suggest a cheaper route. The second locks in a solution you may have picked by accident.
Then say how you will judge it. It does not have to be a number you can promise. It can be a behaviour you will watch: fewer inbound calls asking for opening hours, quotes requested through the form instead of by email, a sales team that stops re-keying leads.
Also state the deadline and what is driving it. A trade show, a contract start, a funding date. A real date changes how a supplier staffs and sequences the work. A vague “ASAP” changes nothing and costs you credibility.
If you cannot say what success looks like, the supplier cannot quote for it. They can only quote for activity.
Describe what already exists
Most projects are not greenfield. There is a current site, a spreadsheet that runs operations, a CRM nobody likes, a payment provider with its own constraints. Each of these is a cost driver, and suppliers will only discover them if you tell them or if they discover them mid-project.
Give access where you can: a staging login, a read-only account, a screen recording of how the process works today. A ten-minute recording of someone doing the job often replaces a page of description.
- Current site or system: platform, hosting, who has admin access, and what is staying versus being replaced
- Content: who writes it, whether it exists yet, and how many pages or product records need moving
- Integrations: payment, CRM, email, accounting, inventory, anything that must exchange data
- Data: where it lives now, how clean it is, and whether it needs migrating
- Constraints: required hosting, security or compliance requirements, accessibility expectations, languages
Name the people and the decision path
Delays in web and software projects usually come from approvals, not from engineering. Tell the supplier who the day-to-day contact is, who signs off, and how many people have an opinion. Three stakeholders who each see the work only at the end is a different project from one decision-maker who sees it weekly.
Be explicit about what you will provide and by when: copy, images, brand assets, access, test data, answers to questions. A fixed-price quote usually assumes you supply these on time. If you know you will not, say so and ask for the work to be priced.
Put a range and a priority order on the table
Sharing a budget range feels like showing your cards. In practice it does the opposite of what people fear. It lets a supplier tell you what fits, what has to be cut, and what a phased version would look like. Without it, you get quotes aimed at an imagined budget.
Sort your wishes into three piles: must have for launch, should have soon after, and nice to have. When the quote comes in higher than expected, you already know what moves to phase two. This is far better than renegotiating scope under pressure.
A good supplier will push back on your brief. Treat pushback as a free review, not as friction.
Ask for a quote you can compare
Once briefs are sent, the replies are where you find out who listened. Ask each supplier to state their assumptions, what is excluded, how many revision rounds are included, and how changes are handled. A quote with no stated exclusions is not cheaper. It is just unfinished.
Pay attention to the questions they ask. A supplier who asks about your data, your approval process and your edge cases is pricing the real project. A supplier who sends a number the same afternoon is pricing the average one.
- What is explicitly included and excluded?
- What assumptions would change the price if they turned out wrong?
- How are changes requested, estimated and approved?
- Who does the work, and who is your day-to-day contact?
- What happens after launch: support, fixes, hosting, handover of code and accounts?
Takeaways
- Write the outcome and how you will judge it before any feature list.
- Document what exists today, including integrations, data and access.
- Name decision-makers and commit to what you will supply and when.
- Share a budget range and a must, should, nice priority order.
- Compare quotes on assumptions and exclusions, not just the total.
Related services
