Working with a Web Agency

A web agency can coordinate strategy, design, development, content and launch, but the word “agency” does not guarantee that all of these services are included or performed by a senior team. A successful relationship depends on clear scope, named responsibilities, account ownership and practical acceptance tests.

Understand who will do the work

Ask for the delivery structure:

• who leads discovery;
• who designs the site;
• who develops and tests it;
• who writes or enters content;
• who handles migration and redirects;
• who provides support after launch;
• whether any work is subcontracted.

The person presenting the proposal may not be the person managing or producing the website. That is not necessarily a problem, but it should be transparent.

Give every agency the same brief

Provide a consistent description of:

• business objective and audience;
• required pages and functions;
• existing website and accounts;
• content readiness;
• integrations and data;
• launch constraints;
• maintenance expectations;
• budget or procurement limits.

Otherwise, one agency may quote for a thorough migration and another may assume the old content will simply disappear.

Compare scope, not presentation

Areas to compare in agency proposals

Area	Questions
Discovery	What decisions and documents will it produce?
Design	How many templates, states and review rounds are included?
Content	Who writes, edits, sources and uploads it?
Development	Which platform, integrations and environments are included?
Migration	How are URLs, redirects, media and metadata handled?
Testing	Which devices, browsers, tasks and accessibility checks are covered?
Launch	What backup, rollback and monitoring process is used?
Support	What response, allowance, exclusions and recurring fees apply?

Keep business-controlled accounts

The business should control the domain and should be able to access hosting, DNS, analytics, Search Console, payment and other critical services. The agency can receive appropriate user access without becoming the sole owner.

Use named accounts rather than a shared administrator login. Remove access when people leave the project and store recovery information safely.

Agree how decisions and changes work

Record:

• the person authorised to approve work;
• the number of review rounds;
• what counts as a correction and what counts as a change;
• the rate or method for additional work;
• the effect of late client content or approvals;
• how scope changes are documented.

A change request should explain cost and schedule effects before work begins.

Review progress through working evidence

Ask to see:

• approved page maps and wireframes;
• real content in key templates;
• the working test environment;
• form and integration tests;
• the migration and redirect plan;
• open risks and known limitations;
• the launch checklist.

Do not wait until launch day to discover how the mobile menu, checkout or CMS works.

Plan handover from the start

Specify the final package:

• administrator and service access;
• source and design files where included;
• licence ownership and renewal dates;
• content and data exports;
• backup and restoration instructions;
• CMS training;
• known limitations;
• support and exit arrangements.

Warning signs

• guaranteed rankings or traffic without evidence;
• unclear ownership of the domain or platform account;
• a fixed quotation with no meaningful scope;
• no explanation of migration or redirects;
• all services described as “included” without deliverables;
• pressure to approve before questions are answered;
• no backup, testing or rollback process;
• no route for transferring the site.

Sources checked

• National Cyber Security Centre: Secure your important online accounts
• National Cyber Security Centre: Protecting your public domain name

Account-security guidance checked on 21 July 2026.

The next practical step is to turn the preferred agency proposal into a deliverables and ownership checklist before signing.