How to choose a web development agency: twelve questions before signing

Why comparing on price does not work

Three proposals for the same project arrive with a fourfold spread. That is normal and says almost nothing about quality.

The spread does not come from greed. It comes from all three understanding the job differently: one priced a template and content loading, the second bespoke design and integrations, the third never grasped that the data would run to a thousand items.

So the first step to comparable prices is not requesting quotes but giving everyone the same brief. While the brief differs, you are comparing assumptions rather than suppliers.

And once the brief is the same, price stops being the main criterion and the questions below start to matter.

Look past the portfolio to what happened after launch

A portfolio shows what a site looked like on handover day. That is the least informative state it will ever be in.

Ask three things about any piece in it: is the site alive now, who runs it after launch, and what changed on it over a year.

The answer the client took it from there is common and not bad in itself. It is bad if every piece gets the same answer: nobody stayed, and you will be the first to find out what happens after six months.

Open two or three portfolio sites during the meeting itself. Check they load, that forms work, that there are no empty coming soon sections. It takes three minutes and tells you more than the presentation.

And look at the dates. A portfolio whose newest piece is four years old means either the team has changed or there is nothing to show.

Twelve questions: about the work

The first group is about how this will actually run.

Who specifically will do the project, and are they on something else right now. A name, not our team. That is the person you will be dealing with.

What the process looks like: how many stages, what is shown at the end of each, and when you first see a working version rather than a picture.

What happens when a deadline moves. Not we do not move deadlines — everybody does — but how you are told and how early.

Who writes the text and whether that is in the price. The most common source of delay and the most common omission from a quote.

Twelve questions: about money

The second group is the one that causes most of the arguments mid-project.

What the quoted figure includes and what it does not. Ask for the list of what is billed separately rather than the list of what is included: the second always reads better.

How changes are billed. Hourly rate, minimum unit, turnaround on estimates. Agreeing this before the first change costs a fraction of agreeing it afterwards.

What support costs after launch and what it covers. An answer of support is free means it is priced in or it does not exist.

What happens to payment if the project stops. A rare situation, but the terms for it are written beforehand, not at the moment it happens.

Twelve questions: about life after launch

The third group, which almost nobody asks, determines what you actually end up owning.

Who owns the code, and in whose name the domain and hosting are registered. The right answer is yours. A domain held by the supplier turns every later conversation into a hostage negotiation.

What you receive at completion: credentials, source files, instructions for updating content.

Whether another developer could pick the work up, and on what basis. Standard technologies, a conventional structure, readable code — or an in-house system only they know.

And who answers when the site stops loading on a Saturday. Is there a number, a response time, and a definition of what counts as an outage.

Three answers worth walking away from

Not signs of incompetence, but signs the relationship will be hard work.

A brief is not necessary, we understood everything. Sometimes they genuinely did. But at handover there will be nothing to check against, and whoever speaks with more confidence will be right.

We will do it in a week. For a three-page site, true. For anything else it is either an untouched template or somebody who did not estimate and wanted to close.

We will quote once we start. An estimate can be a range and it can be staged, but its absence means the entire risk has been moved onto you.

Fixed price or hourly

Both models work, and the choice follows from how well defined the job is, not from preference.

A fixed price suits a defined scope. It gives predictability and moves risk to the supplier, who prices a buffer for it — usually twenty per cent or more.

Hourly is more honest when the work is exploratory and the exact scope is unknown up front. But it demands your involvement: without oversight the hours grow, and that is rarely malice, more often an absent boundary.

The sensible compromise is a fixed price on the defined part and hourly on anything beyond the brief. Then both sides know where the line sits.

And in either model, ask for a breakdown by stage with a figure against each. A single number for everything lets you neither compare nor stop halfway.

What the contract needs to contain

A short list, each missing item of which costs more than it appears to.

The scope of work, referencing the brief as an appendix. A contract without that appendix describes an intention rather than a job.

Deadlines by stage and what happens when they are missed on either side. Clients miss deadlines too, through approvals and text.

The acceptance procedure: who, within how many days, against what criteria, and what counts as silent approval.

Rights to the result and the handover of credentials. And the line between a defect fixed at no charge and a change quoted separately.

How to compare proposals against each other

When three quotes arrive, comparing them line by line is useless: they are structured differently.

Reduce them to a common shape. Write five or six rows: design, build and development, content loading, integrations, first-year support. Distribute each proposal's figures across them.

The empty cells are the interesting part. If one supplier has nothing under content loading, that is not cheaper — it means you will be doing that work.

Separately, total the first year rather than the launch. A cheaper site with support at twice the rate costs more by the tenth month.

And compare timelines not by the final date but by the date you first see a working version. That one tells you more about the process.

What shows up in the first meeting

A few signals that appear well before any paperwork.

Whether they ask about the business or go straight to pages. A supplier who has not asked in an hour where your customers currently come from will build a site in general.

Whether they push back. Someone who agrees with every idea you have is either not listening or not going to object later, when objecting is what you need.

Whether they mention what they will not take on. That is a mark of experience: everybody has work they decline, and a direct refusal is more reliable than universal agreement.

What not to demand

Three demands that sound reasonable and leave you worse off.

Guaranteed search positions. Nobody controls the results page, and promising a specific place means either ignorance or a bet that you will not check.

Free changes forever. There is no such thing: either it is priced in up front, or it ends the moment it stops being profitable.

Full prepayment in exchange for a discount. The discount rarely covers the lost leverage: while part of the sum is unpaid you have an argument, and afterwards only goodwill.