Skip to content
Home About Services Portfolio Blog Contact Get Started
Web Development

How to Choose a Web Development Agency: The Vetting Checklist That Actually Works

Written by

MTD Technologies

Published
Read Time 10 min
Business person reviewing a website wireframe with a magnifying glass and checklist when choosing a web development agency

Learning how to choose a web development agency is one of those skills that feels optional right up until you hire the wrong one. A bad agency relationship costs you six months, a five-figure invoice, and a website your own team is afraid to touch. After more than nine years shipping web projects at MTD Technologies, I can tell you the difference almost never comes down to the pitch deck. It comes down to the boring vetting work this guide walks you through.

This is written for business owners, marketing managers, and founders who need to hire a development partner. By the end, you will have a practical checklist you can run on every finalist: how to define what you actually need, how to vet a portfolio, the red flags that should stop you, how to read a proposal, and how to make sure you own everything you paid for.

Step 1: Define the outcome before you talk to anyone

Most agency searches start with “we need a new website” and skip straight to portfolios. That is backwards. Before your first call, write down the primary outcome in numbers (qualified leads, online sales, booked demos — “40 qualified demo requests a month” invites a serious conversation; “we want more leads” invites a pretty homepage), the timeline you actually need, and who owns the project on your side. Agencies cannot estimate honestly without these, and the ones that try are estimating from a template.

Also decide your non-negotiables early. If your team must publish blog posts and landing pages without calling a developer, say so. If the site must pass Core Web Vitals on mobile, say so. These constraints eliminate agencies fast, and that is the point: a shortlist of two strong fits beats a beauty parade of eight.

Step 2: Vet the portfolio like a sceptic

Portfolios show what an agency can make look good, not what it can make work. Run every portfolio through this filter:

  • Open the live site, not the screenshot. Click through it on your phone and on a laptop. If the agency cannot give you live URLs for its best work, treat every screenshot as unverified. Agencies that are proud of their engineering will hand you URLs before you ask.
  • Check speed yourself. Run their recent launches through Google PageSpeed Insights on mobile. Their portfolio’s real performance is their most honest promise — if their own clients’ sites load in eight seconds, yours will too.
  • Ask who did the work. Some agencies present partner or white-label work as their own. Ask directly: which of your current employees built this, and can I meet them? Hesitation here tells you a lot about what your project would actually look like internally.
  • Look for relevant complexity, not relevant industry. An agency that built a fast, conversion-focused booking flow for a dentist has proven the skills your booking flow needs. Ignore industry labels; verify the underlying mechanics.

Then call references — and ask the questions that surface real information: whether the project finished near the original timeline and budget, how delays were communicated, who actually did the hands-on work, and what the reference would do differently if they started again (a ten-question screening checklist worth borrowing). If every reference gives you a perfect, frictionless story, dig deeper. Real projects hit friction; the value of a reference call is hearing how that friction got handled.

Red flags to watch for when you choose a web development agency

Any single one of these deserves a hard pause. Two or more is your answer.

  • Guaranteed rankings or conversion rates. Nobody can guarantee search rankings — Google itself warns against anyone who claims to.
  • A detailed proposal within a day of first contact. With no discovery call and no questions about your business, that proposal was a template with your name pasted in.
  • No mention of performance, accessibility, or QA. Core Web Vitals, mobile behaviour, and a described testing process are baseline in 2026, not extras.
  • A stack recommendation made before understanding your requirements. If they prescribed a platform before hearing about your team and workflow, they are selling what they sell to everyone.
  • Vagueness about who owns the code. “Of course it’s yours” is not a contract clause. Ownership should transfer to you on payment, with a written IP assignment.
  • Your domain and hosting registered in the agency’s name. The single most common lock-in mechanism we see in rescue projects. All accounts must be in your name or transparently accessible to you.
  • No post-launch support model. An agency that treats launch as the end of the engagement is selling a deliverable, not a growth system. The difference shows up about three months later.
  • Slow or sloppy communication during sales. This is the most reliable preview of how they will communicate once you are a client.
  • A price dramatically below market. That margin gets recovered somewhere — through change orders, locked-in hosting, or skipped testing that resurface as upcharges later.

A sound agency evaluation framework puts it simply: “Polish wins pitches. Evidence protects budgets.” Tape that to your desk during vendor selection.

Red flags to watch for when you choose a web development agency

Step 4: How to read an agency proposal

Look for these in writing. And when comparing proposals, stop comparing headline prices first — compare what each quote excludes; that is where the real price difference normally lives.

  • An itemised scope. Named pages, named features, named integrations. A single lump-sum line like “website development: $25,000” with no breakdown is a number you cannot hold anyone to.
  • Explicit exclusions. Content writing, photography, third-party licence fees, ongoing SEO — every project has items outside the build, and they should be listed, not discovered.
  • A change-order process. You will ask for something new mid-project; everyone does. A good proposal explains exactly what happens: a written change request with its own price and revised date, approved before work starts.
  • Revision rounds per milestone. A number, not “unlimited revisions,” which is a promise nobody can keep.
  • A staging environment and sign-off process. You should open a real link on your phone at every milestone, tap through it, and catch changes early while changing them is cheap. If you would be the first person to click through the finished site, you are doing their QA and paying them for it.
  • Milestone-based payments. Never full payment upfront. A common, fair structure: a deposit, payments tied to signed-off milestones, and a final payment after launch acceptance testing.
  • Warranty and termination terms. Bugs attributable to the original build should be fixed under warranty — typically 30 to 90 days. The contract should also explain how either side can exit and what you receive on exit.

Compare the two or three finalists on the same definition: total cost of everything you need from build through the first year. Then apply the simplest test in procurement: ask every agency the same questions and check whether each answer matches what its proposal puts in writing. What is not written down does not exist.

Step 5: Who owns the code, the domain, and the accounts

This is where more businesses get burned than anywhere else in the process, and it is entirely preventable. Before you sign, get all of this in writing in the contract — not in an email, not verbally.

  • The domain is registered in your account. You hold the registrar login. If the agency registers it for you, the contract must state it transfers to you on final payment.
  • Hosting and services live in your accounts. Hosting, email, payment gateways, analytics — in accounts you own or where you hold owner-level access. Hosting should be a separate, transparent line item, never invisibly bundled, so the relationship continues by choice rather than lock-in.
  • The code and design files are yours once paid. Full repository access, all logins, and short documentation on the project structure — delivered at handover.
  • Third-party licences are inventoried. Premium themes, plugins, stock assets, fonts, APIs: each item, who pays for it, and whose name the licence sits under. A contract that hands over the code but hides a licensing problem has not handed over much.
  • You know what happens if you leave. Notice period, handover of repositories and credentials, and whether they will support a transition. The best time to discuss how the relationship ends is before it starts.

A detailed vetting guide for development agencies puts the underlying principle plainly: a credible agency will not be threatened by these questions — it will welcome them as a sign you are a serious client. The ones most likely to resist transparency around process, ownership, and measurable standards are precisely the ones you should avoid.

Contract and code ownership handover when you choose a web development agency

From our experience: what goes wrong after the contract is signed

Most agency engagements do not fail at selection; they fail at the seams between milestones. The pattern we see most in rescue projects is not incompetence — it is ambiguity that was comfortable during sales and expensive during delivery. “We assumed the copy was included.” “The maintenance plan covered that, right?” Every one of those sentences has a price tag, and every one was avoidable with a written answer before work started.

Two honest realities worth planning for. First, the cheapest competent quote usually wins on total cost of ownership, not the cheapest quote overall: a template-built site that needs rebuilding in eighteen months costs more than a well-built one that compounds. Second, post-launch is where value is made — analytics QA to confirm tracking fires correctly, monitoring so problems surface before customers report them, and a maintained backlog of improvements. If your budget ends at launch day, reserve some: the first three months of iteration decide whether the site performs or just exists.

And one thing clients consistently undervalue: the CMS handover. Ask the agency to demonstrate your team editing a page, publishing a post, and adding a landing page — during the engagement, not after. If only their developers can safely change content, you do not have a website; you have a dependency. Our own web development services are built around exactly this standard: you own the code, the accounts, and the ability to run the site without us.

When NOT to hire an agency at all: if the project is one clear, bounded piece of work and you want to talk directly to the person writing the code, a senior freelancer is often the better fit. If you have continuous product work for years, start building in-house capability. Agencies earn their fee when you need design, content, and development moving in parallel — including custom API development and third-party integrations — with one accountable team.

Frequently asked questions

How much does it cost to hire a web development agency?

A professional business website typically runs from a few thousand dollars for a focused marketing site to $25,000–$75,000+ for complex builds with custom functionality and integrations. Compare proposals on total first-year cost — build plus licences, content, and support — on the same definition of scope. The useful question is always what each quote excludes.

How long should a typical business website take to build?

A standard marketing site takes 6–12 weeks from kickoff to launch; complex builds with custom features or integrations run 3–6 months. Be wary of same-week start promises — legitimate teams usually begin two to three weeks after the first call, once discovery and scheduling are done.

Should I hire an agency or a freelancer?

Hire a freelancer for one clear project where you want to talk to the person writing the code. Hire an agency when you need design, content, and development in parallel with a single point of accountability. Agencies cost more per hour but remove the coordination burden — which is usually where freelance engagements quietly stall.

What should be included in a web development contract?

At minimum: an itemised scope with exclusions, a change-order process with its own pricing, milestone payments tied to sign-offs, revision rounds per milestone, a warranty period for build-attributable bugs, written IP transfer covering code, design files, and content, all accounts registered in your name, post-launch support terms with response expectations, and termination terms including what you receive on exit.

Can I switch agencies later if I am not happy?

Yes — but only if you secured the fundamentals at contract time. With the domain, hosting, and repository in your name and documentation delivered at handover, a new team can pick up the work in days. Without them, switching means rebuilding from fragments. This is why ownership terms belong in the contract before the first invoice, not during the first dispute.

Choosing a web development agency well is mostly a matter of refusing to skip the boring parts: name the outcome, verify the portfolio with live evidence, read the proposal for what it excludes, and get ownership in writing. If you would like a second opinion on a proposal you are evaluating, or a transparent quote built the way this guide describes, contact us — we answer agency-vetting questions for free, even when we are not the agency being vetted.