How to Choose a Web Design Agency Without Buying a Sales Pitch

Before you contact an agency

Write a one-page brief answering:

• Why is the project happening now?
• What is wrong with the current experience?
• Who is the primary audience?
• What should a valuable visitor understand or do?
• Which content, systems, and integrations already exist?
• What must be preserved—URLs, data, brand equity, workflows, analytics?
• Who makes the final decision?
• What budget and date constraints are real?
• How will the business judge the result?

You do not need to prescribe the solution. A good brief defines the problem and constraints clearly enough for agencies to reveal how they think.

Test 1: can they sharpen the problem?

In the first conversation, notice the ratio of questions to claims. Strong teams ask about customers, acquisition, content, internal operations, current evidence, and the reason behind requested features.

They should be willing to challenge the brief respectfully. If you request a complex calculator, they might ask which decision it improves and whether a simpler comparison would do the job. That is not resistance; it is evidence that they distinguish an instruction from an outcome.

Be cautious when every early question is about page count, favourite sites, and desired animation. Those inputs matter later. They are not the foundation of a business website.

Test 2: meet the people who will do the work

Ask who will lead strategy, design, development, content, SEO, and project decisions. Then meet the key people before signing.

Questions to ask:

• How many projects will you handle alongside ours?
• Which parts will be subcontracted?
• Who reviews the code and design?
• Who speaks with us each week?
• Does the pitch team remain involved?
• What happens if a key person becomes unavailable?

Team size is less important than continuity and authority. Direct access to makers is valuable only if those makers can also make decisions.

Test 3: interrogate the portfolio

Do not ask only whether you like the work. Ask what the agency was responsible for and what changed.

For two relevant projects, request:

• the original problem and constraints;
• the agency's exact scope;
• one difficult trade-off;
• what was reused versus custom-built;
• launch performance and accessibility evidence;
• the result, with the limits of attribution;
• what they would do differently now.

A credible answer separates facts from inference. “Conversion rose after launch” is evidence. “Our redesign caused the entire increase” may not be, especially when campaigns, pricing, or seasonality changed too.

Test 4: look past surface similarity

Industry experience helps when regulation, buyer behaviour, content, or integrations are genuinely specialised. It can also produce formulaic work.

Prioritise analogous complexity over identical logos. An agency that has structured a multilingual research library may be more relevant to your professional-services site than one that has produced ten visually similar sites in your sector.

Ask: have they solved our kind of problem?

Test 5: inspect the proposed process

A useful process explains how uncertainty becomes decisions. It should show:

1. how discovery produces scope and architecture;
2. when content is written and approved;
3. how structure is validated before visual polish;
4. when development begins;
5. how design and engineering resolve changes;
6. how CMS, accessibility, performance, and SEO are tested;
7. how migration and launch are controlled;
8. how the result is measured after release.

Avoid both extremes: a rigid ceremony performed regardless of the project, and an undefined promise to “collaborate closely.” The process should adapt while retaining clear decision gates.

Test 6: make the proposal comparable

Ask every shortlisted team to state assumptions for:

• discovery and research;
• sitemap and information architecture;
• number of unique templates;
• copywriting and content entry;
• CMS content types and permissions;
• integrations;
• responsive and interactive states;
• accessibility target;
• performance target;
• technical SEO and redirects;
• browser and device QA;
• analytics and consent;
• hosting, warranty, and maintenance;
• feedback rounds and client responsibilities.

Then compare the same work. A low quote is not suspicious because it is low. It is risky when nobody can explain which responsibilities have been removed.

The companion guides on custom website cost and website timelines show how those assumptions affect budget and calendar.

Test 7: ask how they handle content

Content is not material poured into finished boxes. It determines architecture, hierarchy, page length, proof, calls to action, and CMS structure.

The agency does not need to write every word, but it should provide a content process. Ask:

• Who owns each page draft?
• When must copy be available?
• How are current pages audited?
• Who decides what to keep, merge, redirect, or remove?
• How are claims and evidence reviewed?
• Does design begin with real content?

If the answer is “send the copy when it is ready,” the timeline is carrying an unnamed risk.

Test 8: demand quality evidence

Ask the team to show how it validates—not merely promises—quality.

Useful evidence includes:

• Lighthouse and real-user performance data;
• keyboard and screen-reader checks;
• automated and manual accessibility testing;
• responsive browser QA;
• redirect and metadata validation;
• error monitoring and form testing;
• code review and deployment controls;
• a launch and rollback checklist.

Numbers need context. A desktop Lighthouse screenshot is not proof that mobile users experience a fast site. Google defines Core Web Vitals from real-world loading, interaction, and visual-stability data; ask how the agency watches those signals after launch, too.

Test 9: check how design meets development

Many website failures happen between approved interface and production code. Ask:

• Does the developer join before design is complete?
• Are components and states considered during design?
• Who decides when implementation exposes a missing state?
• Is the design system reflected in code?
• Who checks that production matches the intent?

If the agency describes a clean “handoff” in which design disappears and engineering begins, understand who owns the inevitable decisions between the files.

Test 10: clarify ownership and portability

The contract should state that, after agreed payment, you own or retain appropriate rights to:

• the domain and DNS account;
• website content and original media;
• design source files;
• custom source code;
• analytics, tag manager, and search accounts;
• CMS and hosting access;
• documentation and deployment instructions.

Third-party frameworks, fonts, plugins, and platforms have their own licences. Those should be listed, not disguised as custom intellectual property.

Ask what happens if you leave. A confident partner makes the exit possible even while working to make it unnecessary.

Test 11: understand change before it happens

No complete website project follows the first scope exactly. The contract should distinguish:

• clarification of agreed work;
• correction of defects;
• reasonable design iteration;
• a genuinely new requirement;
• a changed assumption or dependency.

Ask for an example of a previous scope change and how it affected cost and date. Look for a process that makes trade-offs visible, not one that either says yes to everything or monetises every conversation.

Test 12: evaluate the working relationship

Before a large engagement, consider a bounded paid discovery or audit. It can produce useful work—scope, architecture, risk map, or prototype—while showing how the team listens, documents, challenges, and decides.

During selection, notice:

• Are answers direct?
• Do they admit uncertainty?
• Do follow-ups arrive when promised?
• Are decisions written down?
• Does the team reduce confusion?
• Can they explain technical choices without theatre?

The project will amplify the behaviour visible during sales.

Red flags worth taking seriously

• a guaranteed Google ranking or conversion increase;
• a final quote before integrations and content are understood;
• refusal to identify the delivery team;
• a portfolio with no clear statement of responsibility;
• proprietary lock-in without a documented reason;
• no discussion of accessibility, performance, analytics, or redirects;
• unlimited revisions used as a substitute for a decision process;
• full payment tied to dates the agency controls but not to deliverables;
• a launch plan that ends at “point the domain”.

One red flag may have an explanation. A pattern is the operating model.

A simple scorecard

Score each shortlisted agency from 1–5, then write one sentence of evidence for the score.

Weighting price at 5% does not mean budget is unimportant. Treat the budget as a threshold first: remove proposals you cannot responsibly fund, then select among viable options by expected value and risk.

Sources

• Google Search Central: Understanding Core Web Vitals
• W3C: Web Content Accessibility Guidelines

Common questions