"Send me a quote for a website" gets you a number that is either padded to cover the unknowns or low enough to guarantee an argument later. Neither helps you.
You do not need a specification document. You need answers to six questions, and they take about half an hour. This is what we ask for, and it is worth writing down once and sending to everyone you are shortlisting so the quotes are actually comparable.
The six things
- 1. What should it do for the business?Not features — outcomes. "Take bookings so my staff stop doing it on WhatsApp" is a brief. "A modern website" is not. The outcome tells a good developer which features you actually need, including ones you had not thought of.
- 2. Who uses it, and on what?Customers on phones, staff on desktops, field agents on tablets with bad signal. This single answer changes the architecture more than anything else on the list.
- 3. What has to connect to it?Tally, your payment gateway, a marketplace, WhatsApp, an existing database, whatever your accountant uses. Integrations are the biggest source of surprise cost, and naming them up front is the single most useful thing you can do.
- 4. What is the budget range?Withholding this does not get you a better price; it gets you a guess. A range lets a developer propose what is achievable inside it — and tell you honestly if what you want does not fit, which is information you want before you have spent anything.
- 5. When do you need it, and why then?A real deadline (a season, an exhibition, a contract) changes what should be built first. An invented deadline just makes everything more expensive.
- 6. Who decides?Name the one person who can approve designs and sign off milestones. Projects with three equal decision-makers take twice as long, and everyone involved knows this except, sometimes, the three decision-makers.
Useful things to send with it
Two or three sites or apps you like, with a sentence each about what you like — this is worth more than any amount of adjectives. Your logo and brand files if you have them. A rough list of pages or screens, even if it is a phone note. And your current site's analytics, if there is one, because what people already do on it is the best evidence available about what to build next.
What you do not need
You do not need a technical specification, a choice of programming language, or a database design. If a company asks you for those before quoting, they are asking you to do their job. Bring the business problem; the technical decisions are what you are paying for.
What a good developer will ask you back
The questions that come back are a useful signal about who you are dealing with. A company that reads your brief and immediately sends a number has not thought about it. One that comes back with questions has.
- "What happens today?"Someone who wants to understand the manual process you are replacing is planning to fit the software to your business. Someone who skips this is planning to fit your business to their template.
- "How many of these do you do a month?"Volume decides architecture. Fifty bookings a month and fifty thousand are different systems, and getting this wrong in either direction is expensive.
- "Who will maintain the content?"This determines whether you need a content management system at all, which is often a significant line on the quote.
- "What does success look like in six months?"It sounds like a consultant question, but it is the one that decides what gets built first. More enquiries, fewer phone calls, faster dispatch — each points at a different first release.
One thing to do before you send it anywhere
Show the brief to whoever does the work today — the person taking the bookings, packing the orders, answering the phone. They will find the gap between how you think the process works and how it actually works, and they will find it in about five minutes.
That gap is where most mid-project change requests come from, and it is far cheaper to discover it now than in week six.
Frequently asked questions
Should I tell developers my budget?
Yes. The fear is that the quote will expand to fill it, and with an unscrupulous vendor it might. The greater risk is spending weeks on proposals for something you were never going to buy. Give a range, and judge the response — a company that immediately proposes the top of it, with no reasoning, has told you something useful.
How detailed should the brief be?
One page is plenty. Six clear answers beat twenty pages of feature list, because the feature list usually describes a solution someone already picked rather than the problem you have.
How quickly should I expect a quote?
For a well-defined brief, one to two business days for an itemised estimate is reasonable. Longer is fine for a complex platform, but you should hear back the same day about when to expect it.
Want this applied to your project?
Send us what you have — even a rough note. You'll get a written scope, a fixed quote and a delivery date within one business day, with no obligation.