The worst projects we have been called in to rescue started with the best-looking presentations. A deck tells you nothing about timelines, about who will own the code, or about what happens when the site needs changing three months after launch. Below: 15 questions to ask before you sign, what a healthy answer sounds like, how freelancers, studios and agencies differ, and the proposal wording that would stop us signing.

What to do before the first call

These questions only work if every vendor answers the same input. Describe the project slightly differently to each and you get three quotes that cannot be compared — so you pick the cheapest, which is simply the least complete.

• Describe the business problem, not the website. "We need 12 enquiries a month from search" is a brief. "We need a modern site" is not.
• Write a scope list, even if it is one page. The structure is in our guide to writing a website spec.
• State a budget range. Hiding it costs you two weeks — the vendor sizes work to a budget regardless, and will spend that time guessing.
• Name the date you need it by, and why. This alone filters out everyone without a free slot.
• Approach 2 to 4 vendors. One gives you nothing to compare; eight and you choose on likeability.

15 questions to ask before signing

Ask them in writing. Not because you expect dishonesty, but because a written answer becomes part of the agreement and a verbal one becomes nothing.

1. 1Who exactly will work on this? Names and roles. "Our team" means people you have not met, possibly subcontracted.
2. 2How many parallel projects do those people have? More than three per developer and your timeline slips. Arithmetic, not diligence.
3. 3Show me 2–3 sites launched in the last 12 months. An old portfolio reflects the skill of people who have since left.
4. 4Which parts of the portfolio did you build yourselves? A candid split is a good answer. Taking offence is not.
5. 5Can I speak to two past clients? Ask them what went off plan, not whether they were happy.
6. 6What will you build it on, and why that for my case? A CMS, a theme or custom code can all be right — the reasoning must come from your problem.
7. 7What is in the quote and what is not? Ask for a breakdown: research, design, build, technical foundation, testing. One number for everything is not a quote.
8. 8Who writes the copy and sources the images? The commonest cause of a blown deadline is a finished site with no content.
9. 9How many design revision rounds are included? Two or three per layout is normal. Without the clause, somebody overspends.
10. 10What is the payment schedule? Healthy is 30–50% up front, the rest tied to stages. All of it in advance is risky for you.
11. 11Who owns the code, files and accounts after final payment? The answer should be you, with access to repository, hosting and domain.
12. 12What happens if we part ways mid-project? It should be written down: what you receive, what you pay for, how work is handed over.
13. 13What is the warranty period and what counts as a bug? One to three months of free fixes is standard. Draw the "bug versus new task" line early.
14. 14What does support cost after launch? With no answer, you will be alone with the site on the day it goes down.
15. 15What do you need from me, and by when? A vendor who names your deadlines has run projects before. One who says "leave it to us" has not.

Freelancer, studio or agency

This is not a question of quality — every category contains excellent and terrible options. It is a question of risk, and of what you pay for beyond the build.

A practical rule: the more integrations a project has, the less sense it makes to economise on the vendor’s structure. A campaign landing page is freelancer territory; a store with payments, stock sync and a CRM is about who answers the phone in December at peak season.

Red flags in a proposal

None of the items below is disqualifying alone. Three or more together and what you have is not a saving — it is a deferred overpayment.

Comparing quotes and what to fix in the contract

Three proposals at $1,200, $2,800 and $6,000 are almost never three prices for one product. Reduce them to a common denominator first.

1. 1

   Normalise the scope

   List what the dearest proposal includes and the cheapest does not: custom design, templates, integrations, copywriting, testing. The price gap often disappears here.

2. 2

   Find the analytics and testing lines

   These are the first things removed to look cheaper. A site with no analytics events looks identical — until you try to count enquiries.

3. 3

   Calculate a year of ownership

   Build price plus hosting, domain, support and small edits. A cheaper build on a heavy CMS often costs more twelve months later.

4. 4

   Write deadlines with obligations on both sides

   The contract needs your deadlines for content and approvals, not only a launch date. Without that symmetry, a deadline is decorative.

5. 5

   Specify asset handover

   Code, design files in source format, hosting, domain and analytics access, transfer of rights on final payment. One paragraph, years of independence.

One more pre-contract test: ask where projects usually stall. Anyone experienced will say approvals and content, not "the complicated backend". A realistic schedule is laid out in our walkthrough of website project stages.

Frequently asked questions about choosing a web agency

In short

• Give every vendor the same input, or you compare wording rather than proposals.
• Ask in writing about people, code ownership, warranty and support — spoken answers sound identical from everyone.
• A quote with no stage breakdown can be neither verified nor compared.
• Repository, hosting and domain access belong to you from day one.
• The most revealing question is about a project that went wrong. Having no such story is also an answer.