How to Choose a Web Development Agency: 23 Questions Before You Sign

Bad websites rarely begin with an obviously bad developer. More often, they begin with a pleasant conversation, a polished portfolio, and a proposal in which nobody has defined what “done” actually means.

This guide is for a business owner choosing a freelancer, agency, or product team for a company website, service, or online store. It will not identify “the most talented” supplier in one meeting. It will give you a process in which a weak offer is difficult to disguise with charisma.

The short answer: how to choose a web development agency

Do not score taste or the number of technologies in the deck. Score five things: whether the team understands the business problem; the evidence behind its claims; the clarity of scope and assumptions; how you will verify delivery; and what you will own when the engagement ends.

Write a one-page brief before the first call

Do not begin with “we need a modern website.” State who the user is, what action they need to complete, what the business wants to change, the three critical flows, required integrations, who supplies copy and product data, why the deadline is real, and the budget range you can consider.

Add constraints: languages, markets, privacy, payments, CRM, CMS, accessibility, migration, and internal approvers. A good brief describes the problem and boundaries; it does not prescribe 47 pages and a fashionable JavaScript framework. A budget range also stops you comparing a two-week template with a six-month custom platform as though they were the same product.

23 questions before you sign

Strategy and evidence

1. What business problem do you see in our brief? A strong answer reframes the problem instead of repeating your language.
2. What would you deliberately leave out of version one? An experienced team protects focus.
3. Show us two relevant live projects. Which part was yours? Working with a brand does not mean building its whole product.
4. What went wrong on a similar project? Look for a specific mistake, response, and process change.
5. May we speak to a previous client? If that is impossible, the reason and alternative evidence should be candid.

Scope, estimate, and change

6. Which assumptions underpin the estimate? Finished copy, clean data, one approver, and a documented API are material dependencies.
7. What is explicitly included and excluded? Ask about copy, SEO migration, analytics, integrations, browser QA, training, licences, and launch support.
8. Who creates and loads content? A technically complete empty page is not launch-ready.
9. What could change the budget or date most? A mature team names uncertainty before it becomes an invoice.
10. How are changes approved? Require a short description, budget and timeline impact, and written approval.

Team and process

11. Who will actually do the work? Ask for the names and roles of the delivery team, not only the pitch team.
12. What is their availability, and what happens if someone changes? Monthly senior oversight is not senior delivery.
13. How often will we see working software? A demonstration every one or two weeks is safer than a final reveal.
14. Which decisions and materials do you need from us? The schedule should include client dependencies, an approver, and feedback windows.

Technology and quality

15. Which platform or architecture do you recommend, and why? The answer should explain maintenance, editors, integrations, and cost—not fashion.
16. How do staging, version control, review, testing, and deployment work? You should see changes before production and have a rollback route.
17. Which security requirements do you verify? For an application, request a risk-appropriate checklist covering OWASP ASVS requirements, secrets, dependencies, backups, and incidents.
18. Which accessibility level and browser/device matrix are included? Ask for WCAG 2.2 criteria, keyboard testing, and relevant screen-reader checks—not the adjective “accessible.”
19. Which performance targets will we record? Agree the pages, test conditions, and Core Web Vitals or other budgets.

Ownership, launch, and support

20. Who owns the domain, cloud, repository, analytics, and third-party accounts? Your organisation should own them and grant the supplier access.
21. Who owns code, design, content, and data—and what is licensed? Request a register of themes, fonts, plugins, libraries, and stock assets.
22. What does acceptance mean, and how will launch work? Define observable criteria, UAT, owners, backup, rollback, and defect handling.
23. What happens after launch or termination? Clarify warranty, support, SLA, maintenance price, export, documentation, credentials, and knowledge transfer.

Use a 100-point proposal scorecard

Have reviewers score independently, then discuss the largest differences. Do not design a formula in which the lowest price wins automatically. A proposal that omits content, licences, and migration can produce the highest final cost.

Five questions for a previous client

1. What did you intend to receive, and what actually launched?
2. How did the final date and cost differ from the first estimate—and why?
3. Did the team presented to you perform the work?
4. What was the biggest unpleasant surprise, and how did the supplier respond?
5. Would you hire them again for the same kind of project?

Inspect the live product yourself on mobile. Try forms, checkout, keyboard navigation, error states, and performance. Remember that years of post-handoff changes may have altered the product.

What a useful proposal contains

Expect a concise diagnosis, outcomes, scope, exclusions, approach, named team, schedule with client dependencies, milestone deliverables, acceptance, price, payment schedule, change process, assumptions, ownership, warranty, and ongoing costs.

Paid discovery can be fair when integrations or product logic are unknown. It should leave you with usable artefacts: validated scope, flows, architectural decisions, risks, backlog, and a better estimate. Do not demand that every finalist design the whole product for free.

“50% now and 50% when finished” is dangerous if finished is undefined. Prefer payments tied to demonstrable outcomes: agreed scope, tested prototype, working staging increment, content-ready release, and accepted production launch.

What to record in the contract

• deliverables, exclusions, assumptions, and document precedence;
• milestones, client dependencies, review windows, and acceptance;
• fees, taxes, expenses, payment timing, and pause conditions;
• change control and authority to approve additional cost;
• IP ownership, background IP, open-source, and third-party licences;
• confidentiality, personal data, subprocessors, security, and incidents;
• warranties, defects, service levels, and liability limits;
• termination, partial work, repository, export, credentials, and transition help.

Have a lawyer in your jurisdiction review it. Acceptance should describe observable behaviour: not “the form is complete,” but “the form creates a CRM lead with the agreed fields, prevents duplicate submission, displays confirmation, and passes the agreed browser matrix.”

Your website should remain yours

Create accounts under your organisation's email for domain registration, DNS, cloud/hosting, Git repository, CMS, analytics, tag manager, Search Console, payments, email, maps, and consent. Grant the supplier the role required. Google recommends auditing permissions and removing access and verification tokens for people who no longer work on a property.

If moving requires the supplier's permission, you have a dependency rather than a partnership. An exit plan belongs before the first deployment. Google likewise advises planning migrations, testing redirects, preserving Search Console ownership, and monitoring old and new URLs.

Ten red flags

1. You cannot access the repository or production accounts.
2. The supplier permanently owns the domain and hosting.
3. Payment is 100% upfront before any verifiable deliverable.
4. A fixed quote has no assumptions or exclusions for an uncertain problem.
5. “SEO included” has no task list, migration plan, or owner.
6. A proprietary CMS has no documented export path.
7. There is no staging, backup, version control, or rollback.
8. Seniors pitch; the delivery proposal names nobody.
9. The scope lists dozens of features and no non-goals.
10. The portfolio is screenshots without live work, outcomes, or references.

One flag does not automatically mean fraud. It means a question to resolve before the contract—not in month four.

A practical ten-working-day selection

Invite three to five candidates, not fifteen. Give everyone the same brief and shared written answers. Meet the delivery lead, score independently, check a reference, normalise the two finalists' scope, and only then compare price.

Frequently asked questions

Should I hire a freelancer or a web agency?

A freelancer is often faster and less expensive for a bounded task. An agency makes more sense when strategy, design, development, QA, and continuity are needed together. Judge the actual delivery team, not the legal form.

How many website proposals should I get?

Three to five is normally enough. More creates noise when the brief is not yet strong enough to make scopes comparable.

How much should I pay upfront?

There is no universal percentage. A deposit to reserve the team is normal, but later payments should follow clear milestones and acceptance.

Who should own the website, code, and domain?

Your organisation should control the domain, business accounts, data, and repository. Custom-work ownership and third-party licences should be explicit in the contract.

How do I verify a web developer?

Inspect live work and exact contribution, meet the delivery team, speak to a reference, ask about a failure, and score the proposal before signing.

Sources and review date

Reviewed 16 August 2026 against OWASP ASVS, W3C WCAG 2.2, the NCSC's supplier assurance questions, and Google's guidance on Search Console permissions and site migrations. This is a practical procurement guide, not legal advice.

Continue reading: plan an online-store launch, choose an ecommerce platform, and estimate custom AI development.