Choosing a web development agency is not simply a matter of comparing portfolios or finding the lowest proposal. A website project brings together business requirements, content, design, development, accessibility, search considerations, third-party services and ongoing maintenance. The right agency for one project may be unsuitable for another.
A useful selection process therefore examines how an agency understands the project, defines its responsibilities, explains technical decisions and prepares the website for handover. The 12 questions below can be used during initial conversations, proposal reviews and contract discussions. They are not a universal scoring formula. Their purpose is to expose assumptions before those assumptions become delays, additional costs or operational problems.
Define the Project Before Comparing Agencies
An agency cannot prepare a reliable proposal from a request to “build a modern website” alone. Before seeking proposals, document what is already known and identify what still needs expert input.
Start with:
- The business purpose of the website
- The audiences it needs to serve
- The main actions visitors should be able to complete
- Whether the project is a new website, a redesign or a migration
- The page types and functions currently expected
- Existing systems that may need to connect to the website
- Content that will be retained, rewritten or created
- People responsible for decisions, content and approvals
- Known accessibility, privacy, security or regulatory requirements
- Budget constraints and any fixed launch dependency
- The internal team’s ability to update and maintain the website
Not every answer needs to be final. Discovery may change the proposed solution. The objective is to give each shortlisted agency enough context to identify uncertainties and explain how it would resolve them.
A structured website content brief can help organize page purposes, audiences, evidence, responsibilities and intended next steps before content production begins. Functional and technical requirements should be documented separately where the project needs more than a content-focused brief.
1. How Will You Understand Our Business, Users and Website Goals?
The first discussion should not begin and end with preferred colours, visual references or a list of pages. Ask how the agency will learn what the website must help people understand or do.
A considered answer may describe:
- Stakeholder discussions
- Existing website and analytics review
- Customer or user research supplied by the client
- Content and feature inventories
- User journeys or task mapping
- Technical and operational constraints
- Assumptions that require validation
- Measures connected to the website’s purpose
The appropriate discovery process depends on the size and risk of the project. A straightforward informational website may not need the same research programme as an account-based platform or a complex online store. The agency should be able to explain why its proposed level of discovery is proportionate.
Be cautious when a team recommends features before it understands the users, the business process or the information that must support those features. A technically possible feature is not automatically necessary or useful.
2. What Relevant Work Can You Show, and What Was Your Role?
A portfolio can demonstrate design quality and the types of projects an agency has encountered, but screenshots do not reveal the full scope of its involvement. For each relevant example, ask what the agency was responsible for.
Useful clarification includes:
- Whether the work involved strategy, design, development, content or maintenance
- Which parts were completed by the agency and which came from the client or another supplier
- Whether the project was a new build, redesign or migration
- Which constraints influenced the final solution
- Which functions or integrations were included
- Whether the current live website still reflects the agency’s original work
A project does not need to match your business sector exactly to be relevant. Similar user tasks, integrations, editorial workflows or technical constraints may matter more than visual resemblance. Conversely, a website from the same industry is weak evidence if the agency cannot explain its actual contribution.
Treat performance figures and business outcomes carefully. An agency should distinguish results it can substantiate from outcomes influenced by advertising, brand demand, pricing, sales operations, seasonality or later changes made by other parties. Do not ask for confidential client information, but do ask for evidence that can be shared responsibly.
3. Who Will Actually Work on the Project?
The people presenting a proposal may not be the people responsible for delivery. Ask for the roles involved, how responsibilities are divided and who will remain accountable throughout the project.
Depending on the scope, the team may include:
- A project or account lead
- A strategist or business analyst
- A UX or visual designer
- A front-end developer
- A back-end developer
- A content specialist
- An SEO specialist
- A quality-assurance reviewer
- An accessibility or security specialist
Not every website requires a separate person for every role. One qualified person may cover several responsibilities, and agencies may use trusted subcontractors or specialist partners. The important issue is transparency: who will perform the work, who will review it, and who will respond when a decision crosses disciplines.
Ask whether key contributors are employees, regular partners or project-specific subcontractors. If work will be outsourced, establish how the agency selects, briefs and reviews those contributors. Outsourcing is not automatically a weakness, but undisclosed or unmanaged responsibility can become one.
4. How Will You Define and Approve the Requirements?
Requirements turn broad expectations into work that can be designed, built and reviewed. Ask what documentation the agency will produce before implementation and how your team will approve it.
Depending on the project, this may include:
- A sitemap or page inventory
- Page and content requirements
- Functional requirements
- User flows
- Wireframes or prototypes
- CMS and editorial requirements
- Integration specifications
- Data or content migration rules
- Accessibility and security requirements
- Browser and device support
- Acceptance criteria
- Responsibilities and dependencies
The documentation does not need to be unnecessarily complex. It does need to be clear enough that both parties can identify what is included and determine whether the completed work meets the agreed requirement.
Ask how unresolved questions will be recorded. If an integration, data source or business rule has not been confirmed, it should remain an identified dependency rather than quietly becoming an assumption. Also establish who has authority to approve requirements and how approvals will be documented.
5. What Is Included—and Excluded—from the Scope?
Two proposals with similar totals may cover substantially different work. Compare deliverables and exclusions, not price alone.
The written scope should clarify, where relevant:
- Number and types of pages or templates
- Custom functions and integrations
- Responsive behaviour
- Content writing, editing and entry
- Image sourcing or production
- Search and migration work
- Analytics and consent-related implementation
- Accessibility expectations and evaluation
- Testing and review rounds
- Hosting or deployment work
- Domain and DNS responsibilities
- Premium themes, plugins, fonts or software licenses
- Training and documentation
- Maintenance and support after launch
Watch for ambiguous quantities such as “standard pages,” “basic SEO” or “reasonable revisions” unless the proposal explains what they mean. An exclusion is not inherently unfair. It becomes a problem when the buyer reasonably expects the item to be included but the proposal leaves it unclear.
Ask the agency to identify client responsibilities as well. Content, product data, legal wording, account access and approvals often depend on the client. A realistic schedule should reflect those dependencies.
6. Which Platform or Technical Approach Do You Recommend, and Why?
The agency should connect its recommendation to the project rather than presenting one platform or programming language as the correct answer for every website.
Ask how the proposed approach supports:
- Required functions and integrations
- The internal publishing workflow
- Accessibility and responsive behaviour
- Performance requirements
- Security updates
- Expected content volume
- Future maintenance
- Hosting options
- Available internal skills
- Portability and handover
- Ongoing licensing costs
A familiar content-management system may be appropriate when a team needs to manage everyday pages without development support. A more specialized architecture may be justified when the project has unusual application, integration or performance requirements. Neither approach is automatically superior.
Ask which parts depend on proprietary components, paid extensions or third-party services. Confirm what happens if a license expires, a service changes its terms or the business later appoints another developer. This is not a reason to reject third-party tools; it is a reason to understand the dependency before approving it.
The answer should also describe how routine content will be edited. “Editable website” is too broad if the team cannot safely update headings, body copy, images, metadata or repeated content without disrupting the layout.
7. How Will Content, SEO and an Existing-Site Migration Be Handled?
Development decisions can affect URLs, navigation, page content, metadata, internal links, structured data, tracking and search-engine access. If the project replaces an existing website, ask who will inventory the current site and decide what should be retained, consolidated, rewritten or removed.
The migration discussion should cover:
- Current and proposed URLs
- Redirect mapping for changed or removed URLs
- Important content and downloadable assets
- Page titles, descriptions and headings
- Canonical signals
- Internal links and navigation
- XML sitemaps
- Robots directives
- Structured data already in use
- Analytics and search-verification access
- Pre-launch and post-launch checks
Google’s guidance on site moves with URL changes recommends mapping old URLs to new destinations and using server-side permanent redirects where appropriate. A redesign should therefore address migration requirements during planning, not after old URLs have disappeared.
The website redesign SEO checklist provides a fuller framework for protecting search-relevant elements before launch. For a website with existing organic visibility, responsibility for the URL inventory, redirects and validation should be explicit in the agency scope.
For a new site, ask how the agency will make important pages discoverable through navigation and contextual links. A technical SEO audit can examine crawlability, indexing signals and other technical conditions, but it should not be used as a substitute for sound development and launch preparation.
8. How Will You Address Usability, Accessibility and Performance?
These areas should be discussed as requirements and tested outcomes, not treated as interchangeable claims.
Usability
Ask how the agency will review important user tasks on relevant screen sizes. The review should consider navigation, forms, error messages, readable content, interactive controls and the steps needed to complete a key action.
Accessibility
Accessibility should be included in planning, design, development, content and testing responsibilities. The W3C Web Accessibility Initiative recommends including accessibility criteria in requests for quotations and contracts, assigning responsibilities and evaluating accessibility throughout design and development rather than waiting until the end. Its guidance on implementing web accessibility is a useful starting point.
Ask:
- Which accessibility standard or requirements will guide the project?
- Which pages, components and user journeys will be evaluated?
- Which automated and manual checks will be used?
- Who will review issues and confirm corrections?
- What documentation will be provided?
Accessibility evaluation tools can identify some problems, but W3C notes that tools cannot check every accessibility aspect automatically and that human judgement is required. A tool score alone therefore does not establish that a website is accessible. Avoid requesting an unsupported guarantee of compliance. Define the required standard, evaluation method, scope and responsibility instead.
Performance
Ask which performance measures will be assessed, under what conditions and at what project stages. Google describes Core Web Vitals as user-centred metrics, but they are not the only performance considerations. Page weight, image handling, fonts, scripts, hosting, caching and third-party services can all affect the experience.
Performance commitments should distinguish between what the agency controls and what depends on hosting, content, advertising technology, analytics, user devices or external services. A promise of a permanent perfect score is less useful than a documented budget, testing method and process for addressing measured problems.
9. How Will Security, Privacy and Integrations Be Managed?
No agency can credibly promise that a website will never face a vulnerability or attack. A more useful discussion identifies the project’s risks, required controls and ongoing responsibilities.
Ask about:
- Administrative access and user roles
- Credential handling and account ownership
- Software and dependency updates
- Form submissions and stored data
- Backups and restoration
- Logging and monitoring included in the scope
- Third-party integrations
- Development and staging access
- Vulnerability reporting and response
- Security responsibilities after handover
The requirements should reflect what the website does. A brochure site with a contact form does not have the same risk profile as a system processing payments, health information or account data. Where the project is a web application or handles sensitive processes, additional specialist security review may be appropriate.
The OWASP Application Security Verification Standard provides a basis for testing web-application security controls and specifying secure-development requirements. It is not a badge that an agency should claim without defining the applicable version, scope and verification work.
Privacy requirements also depend on the data collected, the people served and the applicable jurisdiction. Ask who decides what data is necessary, who supplies legal or regulatory requirements, and who configures forms, consent tools, retention settings and third-party services. The development agency should not be expected to invent legal requirements outside its agreed expertise.
10. How Will the Website Be Tested and Launched?
“Testing included” is not specific enough. Ask for the planned test areas, environments, responsibilities and acceptance process.
A relevant launch plan may include:
- Review of agreed pages and templates
- Navigation and internal-link checks
- Form and email-delivery tests
- Account, checkout or other functional journeys
- Responsive and browser checks
- Accessibility evaluation
- Performance review
- Metadata and indexability checks
- Redirect testing
- Analytics and consent configuration checks
- Backup confirmation
- Production-domain and HTTPS checks
- A list of known issues and agreed decisions
- A rollback or recovery plan appropriate to the project
Testing should be connected to the requirements agreed earlier. If the project specifies a particular integration, user journey or accessibility criterion, the acceptance process should show how that requirement will be evaluated.
Ask who makes the final launch decision and who will be available during and immediately after deployment. Also clarify whether the agency will test the production installation. A staging website is useful for review, but it does not confirm that production redirects, forms, analytics, caching, DNS or server configuration work as intended.
11. How Are Price, Timeline and Changes Controlled?
Price should be examined together with assumptions, deliverables and risk allocation. Ask how the agency calculated the proposal and what could change the cost.
Clarify:
- Whether the work is fixed-price, time-based, phased or a combination
- Payment stages and invoicing triggers
- Assumptions used to prepare the estimate
- Client inputs required to maintain the schedule
- How additional work is estimated and approved
- How many review rounds are included
- What constitutes acceptance of a deliverable
- What happens when a third-party integration creates unexpected work
- Whether unused maintenance or support time carries forward
- Which taxes, licenses or external fees are separate
A fixed price can create budget certainty when requirements are well defined. A time-based or phased arrangement may be more appropriate when discovery is expected to change the solution. The model matters less than whether its consequences are understood.
Avoid treating a fast timeline as evidence of competence without examining dependencies. Content preparation, internal approvals, integration access and feedback can determine the schedule as much as development capacity. Ask the agency to identify the decisions or materials it needs from your team and the effect of late delivery.
The change-control process should be written. A change request should explain what is changing and how it affects cost, timing or other approved requirements before the additional work begins.
12. What Will We Own, and What Happens After Launch?
Ownership and access are easiest to resolve before work starts. The proposal or contract should identify who controls and can access:
- The domain registration
- DNS and hosting accounts
- CMS administrator accounts
- Analytics and search-platform properties
- Source-code repositories
- Design source files
- Written and visual content
- Databases and exports
- Paid themes, plugins, fonts and stock assets
- Third-party service accounts
Some components may be licensed rather than transferred outright. Custom code, open-source software, commercial extensions, fonts and stock images can carry different rights. Ask the agency to identify material restrictions rather than assuming that payment produces unrestricted ownership of every component.
Post-launch arrangements should specify:
- Handover documentation
- CMS or administrator training
- The period and scope for correcting defects
- Maintenance tasks and frequency
- Update and backup responsibilities
- Support hours and response arrangements
- Hosting responsibilities
- How new features will be estimated
- How access and materials will be transferred if the relationship ends
Contract and intellectual-property requirements vary by project and jurisdiction. Obtain appropriate legal advice where ownership, licensing, privacy or liability terms carry material risk. The agency-selection process can expose the questions, but it cannot replace review of the actual agreement.
Compare Proposals Using Evidence, Not Impressions
After the conversations, record each agency’s answer in the same structure. This makes omissions easier to identify and reduces the influence of presentation style alone.
| Evaluation area | Agency’s answer | Evidence or document supplied | Included in writing? | Unresolved question or risk |
| Business and user understanding | ||||
| Team and responsibilities | ||||
| Requirements and scope | ||||
| Platform and dependencies | ||||
| Content, SEO and migration | ||||
| Accessibility and usability | ||||
| Performance and testing | ||||
| Security and privacy | ||||
| Price and change control | ||||
| Ownership and post-launch support |
A numerical score can be useful if your organization already has a procurement method, but it should not create false precision. A business operating a simple informational site may prioritize editing and handover. A company handling account data may place more weight on security, access control and specialist review. Set priorities from the project’s real risks.
Warning Signs That Require Clarification
One unclear answer should not automatically disqualify an agency. It should prompt a more specific question. The following situations deserve clarification before signing:
- The proposal lists broad services without defined deliverables or exclusions.
- The agency cannot explain its contribution to portfolio projects.
- Rankings, traffic, conversions, security or performance are guaranteed without meaningful conditions.
- A platform is recommended before the agency understands the requirements.
- Essential accounts will be created under an individual’s personal ownership.
- Content, redirects or migration work is assumed to happen after development.
- Testing is described only as checking that the website “works.”
- Accessibility is reduced to an automated score or a plugin.
- Security is reduced to installing a certificate or naming a security product.
- Change requests and additional costs have no approval process.
- Licensing, source files, account access or handover are left undefined.
- Maintenance is offered without saying what will be monitored, updated or supported.
The useful response to a warning sign is not an accusation. Ask the agency to clarify the scope, provide the relevant document or amend the proposal. A clear written answer may resolve the concern; continued ambiguity may reveal a risk the business should not accept.
Final Decision Checklist
Before appointing an agency, confirm that:
- The website’s purpose, audiences and important user tasks are understood.
- Discovery activities and outputs are proportionate to the project.
- Deliverables, exclusions and client responsibilities are written.
- The proposed team and external contributors are disclosed.
- Technical recommendations are connected to the requirements.
- Content, SEO and migration responsibilities are assigned.
- Accessibility, performance and security requirements are defined.
- Testing, acceptance and launch responsibilities are documented.
- Price, payment stages, dependencies and change control are clear.
- Domains, accounts, source materials and licenses are addressed.
- Training, maintenance, support and exit arrangements are understood.
- Material unresolved risks have an owner and a next action.
The final choice may still involve judgement. A strong proposal does not eliminate every uncertainty; it identifies uncertainty, assigns responsibility and explains how decisions will be made.
Frequently Asked Questions
How many web development agencies should a business compare?
There is no universally suitable number. Compare enough credible options to understand differences in approach, scope and cost, but keep the shortlist small enough that each proposal can be reviewed properly. Inviting many agencies to prepare detailed speculative work can consume time without improving the decision.
Should I choose a web development specialist or a full-service agency?
Choose according to the work that needs to be coordinated. A specialist may suit a technically focused project or complement an existing internal team. A broader agency may be useful when strategy, content, design, development and marketing need coordinated responsibility. In either case, verify who will perform each part of the work.
Is the cheapest web development proposal usually a bad choice?
Not necessarily. A lower proposal may reflect a narrower scope, a simpler technical approach or lower operating costs. It may also omit work another proposal includes. Compare requirements, deliverables, dependencies, licenses, maintenance and change-control terms before comparing totals.
Should the business own the website and its accounts?
The required arrangement depends on the project and the licenses involved. The contract should clearly state ownership and access for the domain, hosting, content, code, design files, data and third-party accounts. Where a component cannot be transferred, the restriction and its operational effect should be understood before approval.
Can a web development agency guarantee search rankings or business results?
A development agency can commit to defined work, testing and technical requirements within its control. Search visibility and business outcomes also depend on content, competition, demand, marketing, pricing, sales processes and later website changes. Google states in its guidance on hiring an SEO that no one can guarantee a number-one ranking. Treat unconditional outcome guarantees cautiously.
Choose Clarity Over the Most Impressive Pitch
The right web development agency is not necessarily the largest team, the cheapest supplier or the company using the newest technology. It is the agency whose proposed approach fits the project and whose responsibilities, assumptions, evidence and limitations can be examined before work begins.
Use the 12 questions to compare agencies consistently. Resolve important gaps in writing, review the agreement carefully and retain control of the accounts and information the business will need after launch.
Businesses can apply this framework independently. Where development support is required, Glorvix web development services can be discussed against an agreed brief, scope and set of responsibilities.