Twenty questions to ask a web development agency before you sign anything
Almost any established firm can build a competent website, so capability is not what separates proposals. What separates them is who does the work, what counts as finished, who owns the code afterwards, and what the contract says once the relationship stops being enjoyable. Here are twenty questions that surface all four.
The pitch meeting is an unrepresentative sample
Every agency is at its best in the room where it is trying to win you. The people presenting are the most senior and most articulate in the firm, the deck was made for you, nothing has gone wrong yet, and nobody is defending a missed date.
None of that is dishonest. It is simply a poor sample of what you are buying: the working relationship is made of an afternoon when a third-party API changes without notice, a review round where legal returns forty comments, a stretch when the one person who understands the build is on leave.
Which is why questions about capability are close to worthless. Every proposal asserts capability and most firms have it — building a competent marketing site is not a rare skill. The questions worth asking are about what happens under pressure: who does the work, what counts as finished, who owns what, and what the paperwork says once the relationship stops being fun.
Twenty of them follow. Do not ask all twenty in one meeting; pick the ones matching your risk, since a brochure rebuild and a customer portal fail in quite different ways. Ask for the answers in writing, too — a written answer is a considered one.
Questions about the people who will actually do the work
1. Who specifically is on this project, and are any of them in this room?
The gap between the team that pitches and the team that delivers is the most common disappointment in agency work. Ask for names, roles and the share of their week you get. A good answer is specific and slightly uncomfortable: “two developers at roughly sixty per cent each, a designer for the first phase only, and me about a day a week.” A bad answer describes a department. If none of the named people are present, meet the delivery lead before signing rather than at kickoff.
2. Which parts of this are subcontracted or white-labelled, and to whom?
Subcontracting is normal, and buying in a specialist for accessibility auditing, illustration or load testing beats pretending to be one. It becomes a problem when it is undisclosed and covers the core build, because you are then paying one firm to manage another with no line of your own. Ask which parts are done by people the agency does not employ, in which time zone, and who reviews that work before it reaches you. An agency that white-labels the whole build is a broker; brokers can be worth their margin, but you should know you are buying one.
3. What happens if the person leading this leaves halfway through?
Every firm has a bus factor and most have not considered yours. Nobody can promise continuity, so the real question is whether the project survives a departure without you paying for the same work twice. Ask what documentation exists as routine rather than at handover, whether anyone else there has shipped this stack, and where the code lives today. “We will give you the repository at the end” answers a different question, and not reassuringly.
4. How much of my team’s time does this need, and from whom?
Projects slip on the client side more often than agencies admit during a pitch. Ask them to quantify it: how many review rounds, how long each window is, who must attend the discovery workshop, who writes the copy, whose approval unblocks a milestone. If usability testing is in scope, ask who recruits participants — nearly always a client job, and since Nielsen Norman Group’s long-standing argument is that three rounds of five participants beat one round of fifteen, it is several small asks rather than one.
Questions about process, milestones and change control
5. What are the milestones, and what are the acceptance criteria for each?
“Design sign-off” is not a milestone until somebody writes down what sign-off means. Acceptance criteria turn a payment trigger into something inspectable: all templates at three breakpoints, every interactive component with its states drawn, a documented content model. The UK government’s contracting for agile guidance advises against tying payment milestones to the agile process itself, such as completing a set number of sprints, and stresses including non-functional requirements in what gets paid for. Speed, accessibility and security are the ones that get deferred.
6. What is the change request process, and what does a change cost besides money?
Every project changes; change control is what stops a budget being renegotiated by attrition. The useful question is whether the process is built to be used or built to deter, so ask to see the actual form. Then ask the half people forget: what does a change do to the date, and what comes out to make room? The same guidance describes an intelligent client function that keeps control of scope, including moving items up and down the backlog. That is the honest framing — you do not get more for free, you choose what is dropped.
7. What will I see between milestones, and where?
A weekly call with no working software attached is a status ritual. A staging environment you can visit whenever you like, updated continuously, is a different relationship: it lets you notice in passing that a form label is wrong, rather than in a formal review much later, when changing it has become a change request. Suppliers who show work only at contractual review points are suppliers where surprises accumulate.
8. What does discovery produce, and am I allowed not to proceed?
Discovery earns its cost when it can change the answer. The GOV.UK Service Manual is blunt: “It’s not a failure to stop at the end of the discovery phase if your research shows that’s the best thing to do.” A firm that treats discovery as a paid preamble to a build that was always happening is selling a formality. Ask what the deliverable is, whether you own it outright, and whether you could take it elsewhere. This is also where UI/UX design earns its keep, because decisions made on cheap artefacts are still affordable to reverse.
Questions about technology, ownership and lock-in
9. What are you proposing to build this on, and what did you consider instead?
Nothing is wrong with a default stack: depth in one toolset beats shallow familiarity with six. What you are testing is whether the recommendation was made or merely repeated. A good answer names the alternative and why it lost — editorial workflow, hosting constraints, your in-house skills, an integration with an SDK in only one language. An answer containing no trade-off is a preference wearing a recommendation’s clothes.
10. Is any part of this proprietary to you?
Proprietary platforms are not automatically bad; the problem is that the choice usually gets made without the buyer noticing. Ask directly: if we stop working together, does this still run, can another firm maintain it, is there an annual licence, and what happens to the site if we stop paying it? Source code escrow is the standard mitigation, but treat it sceptically unless the deposit includes build instructions and dependencies and someone has tested a restore.
11. Who owns the code, the design files and the content, and when does that transfer?
The question most often assumed and least often documented — and the UK default is not what buyers expect. Intellectual Property Office guidance states that for a commissioned work “the first legal owner of copyright is the person or organisation that created the work and not you the commissioner, unless you otherwise agree it in writing”, and warns that without such an agreement a court may grant the commissioner only a limited non-exclusive licence. So put it in writing.
| Ask for | Why it matters |
|---|---|
| Assignment of the bespoke code, designs and assets, on final payment | Silence does not default in your favour |
| A perpetual, irrevocable, transferable licence to reused agency components | Firms reasonably keep internal libraries; you still need the right to run and modify what is in your site |
| A list of third-party licences and the named licensee | Fonts are the classic failure: a webfont licensed to the agency expires with the relationship |
| Editable design source files, not exported images | A flattened export is not something anyone can extend |
| Repository access from day one | Ownership you cannot reach is a promise, not an asset |
12. Where will this be hosted, who holds the credentials, and who touches our data?
Every account should be in your organisation’s name with the agency granted access, not the reverse: registrar, DNS, hosting, CMS, analytics, certificates, email sending. Recovering a domain from a departed supplier is miserable and entirely avoidable at the outset. Data is a separate question. In UK and EU law the governing distinction is controller and processor — the controller “determines the purposes for which and the means by which personal data is processed”, while a processor acts “on that controller’s documented instructions”. For a site with a contact form, you are the controller and the agency and its host are processors, which needs writing down along with who the subprocessors are.
13. What is your security baseline, and who patches it after launch?
For a marketing site, ask what happens to dependency and platform updates once the project closes: who applies them, how often, and whether that is included or billable. Unpatched dependencies are how most small sites are eventually compromised, and “the site is finished” is not a security posture. For anything holding accounts or payments — the territory of web application development — ask which standard they build against. The OWASP Top 10 is the usual reference, and a supplier who raises broken access control unprompted tells you more than a certificate logo does.
Questions about performance, accessibility and search responsibility
14. What performance targets are you committing to, and how will they be verified?
“Fast” is not a specification. Core Web Vitals are: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, assessed at the 75th percentile of real page loads and split by mobile and desktop. Ask whether the target offered is a laboratory score on a developer’s machine or field data from actual visitors, because the two diverge sharply on real mobile connections. Then ask what they will tell you if your own requirements — a video hero, four marketing tags, a chat widget — make the numbers unreachable.
15. What accessibility standard are you building to, and who tests it?
The answer should be WCAG 2.2 at level AA, a W3C Recommendation since December 2024. UK public sector bodies must meet it and publish an accessibility statement; outside that scope the regulations do not bind you, but the Equality Act obligations they build on still shape your exposure. The separating follow-up is whether testing is automated only. Automated checks catch machine-detectable failures — missing alternative text, insufficient contrast, unlabelled inputs — and cannot judge whether a focus order makes sense or whether link text means anything out of context. Those need a person, and that is where the real barriers are. We treat it as a constraint during web design rather than as a pre-launch audit.
16. If this is a redesign, who owns the URL mapping and the redirect plan?
The fastest way to lose organic traffic is to launch a better site at different URLs with nobody responsible for the join. Google’s site-move documentation recommends server-side permanent redirects and is specific about longevity: “Keep the redirects for as long as possible, generally at least 1 year.” Ask who produces the mapping, who tests it before launch, and who watches Search Console afterwards. If the answer is vague, price technical SEO separately rather than hoping, and read our longer account of protecting rankings through a redesign first.
Questions about results, not screenshots
17. Show me something you built that is still live, and what has happened to it since.
Portfolio images show a site on its best day. Ask for URLs and check them yourself: still live, still recognisably their work, quick on your phone on mobile data? Then ask the most revealing question in the process: tell me about a project that went badly. Everyone has several. Listen for whether the account includes their own contribution, or whether every past difficulty was the client’s fault.
18. Which part of that result did you actually cause?
Case studies attribute generously. Ask what else changed during the period a quoted improvement was measured: a pricing change, a funding round, a competitor’s collapse, seasonality, a paid campaign running alongside. An honest supplier separates what they influenced from what merely coincided with them. Google’s guidance on hiring a search supplier is worth borrowing wholesale — it suggests asking past clients whether the supplier “provided useful service, was easy to work with, and produced positive results”, and states flatly that “no one can guarantee a #1 ranking on Google”.
Questions about what happens after launch
19. What is covered after launch, and what counts as a bug rather than a change?
The boundary between defect and change request is where post-launch relationships sour, so define it before it matters: a defect is the thing not doing what was agreed, a change is the agreement moving. Ask what a warranty period covers, what an ongoing support arrangement includes and excludes, and whether the service level is a response time or a resolution time — very different promises, routinely conflated in proposals. Ask who is reachable outside working hours, if anybody, and what the escalation route is.
20. If we want to leave, what actually happens?
Ask about the exit while everyone is still enthusiastic, because that is the only time you will get a calm answer. What notice is required, what is the final invoice, and what do you receive: repository access, documented environment variables, a deployment runbook, design source files, the account transfer list, backups? Ask whether they will talk to your next supplier during handover, and whether that is billable. A firm that has thought about its exit has usually thought about the rest of its process too.
What the contract needs to say that the proposal does not
The proposal describes the good outcome; the contract governs the bad one, and it is worth the hour it takes to read properly.
Check that the statement of work is incorporated by reference, so the scope you discussed is the scope you are owed. Check that the assumptions the price depends on are written down — as we argue in our piece on what actually moves a build’s cost, two quotes that look far apart usually differ in their assumptions rather than their day rate. Confirm that payments attach to deliverables with acceptance criteria rather than to elapsed time. Note whether the liability cap is proportionate to the damage a failure would do to you rather than to the size of the fee. And read the termination clause, since it is the only part of the document you will read carefully if things go wrong.
Answers that should end the conversation
Most warning signs are not villainy. They are usually a firm that sells better than it delivers, which is harder to spot because everyone involved is sincere.
- A guaranteed ranking or conversion rate. Nobody controls the search results, and nobody who has just met your customers can promise how they will behave.
- Refusal to name the delivery team. There is no legitimate commercial reason to withhold who does the work.
- A price with no assumptions attached. The number has no basis, and the basis will be constructed later, in your disfavour.
- “You don’t need to worry about the technical side.” Perhaps not daily, but you will own every consequence of decisions made on that basis.
- Hosting that is included, unlimited and non-transferable. Included hosting is fine; hosting you cannot leave is a retention mechanism.
- Unsolicited outreach claiming to have found errors on your site. Google names this pattern among the things to treat warily when a supplier approaches you rather than the reverse.
- Ownership terms that only surface at handover. If the licence model appears in month six rather than in the proposal, the disclosure schedule was a choice.
How to check references properly
Reference calls are usually wasted because the questions invite a yes. “Were you happy with them?” produces politeness. Process questions produce information.
Ask what the change request process felt like during the difficult part of the project. Ask whether the final invoice matched the estimate, and if not, whether the reason was explained at the time or afterwards. Ask who actually did the work, and whether the client had met those people before kickoff. Ask how long the agency took to respond when something broke at an inconvenient hour, and what the handover pack contained.
Two refinements make this much stronger. Speak to whoever ran the project day to day rather than only the executive who signed it off; they experienced different projects. And choose your own references — pick two sites from the portfolio that were not offered to you, and approach those organisations directly. Nobody offers a reference at random, and the unoffered ones are where the distribution actually lives.
How we answer these same questions
We can state our method, which is ours to state; we do not publish claims about our history that a buyer cannot check. Briefly, then: named people with their allocation written into the proposal, assumptions listed beside the price, acceptance criteria on each milestone including performance and accessibility thresholds, repository and hosting accounts in your name from day one, written assignment of bespoke work on final payment, and an exit process documented before anyone needs it. Where we subcontract a specialism, the proposal says so.
If you would rather put these twenty questions to us directly, that is the better use of an hour — start a conversation, or see what a web development engagement involves first.