How to Choose a Website Development Agency

You need a new website, and every agency proposal promises a polished design, a fast build, and an easy handoff. The harder question is whether the site will work with your lead process, booking system, customer records, and the person who has to maintain it after launch. Choose an agency by testing those operational details—not by picking the portfolio you like most.
Define what the website must do before requesting proposals
A useful agency brief describes business outcomes and workflows, not just page counts and visual preferences. If agencies have to guess what happens after someone submits a form, books a call, or buys a product, their quotes will cover different work—and none may cover what you actually need.
Start with the actions visitors should take. For each action, trace the path from the website to the person or system responsible for the next step. A small service business might map a lead like this:
| Visitor action | What must happen next | What could go wrong |
|---|---|---|
| Requests a quote | Details reach the right inbox or CRM record | The request goes to an unmonitored email address |
| Books a consultation | A calendar event and confirmation are created | The booking exists, but no one receives the details |
| Downloads a resource | The visitor receives it and consent preferences are recorded | The file is sent, but the contact is added to a list without the expected consent |
| Pays a deposit | Payment status is reflected in the business workflow | Staff begin work on an unpaid request |
Give agencies the systems you already use, the content you need to migrate, and any constraints on who can edit the site. Identify what is required for launch and what can wait. “Connect the CRM” is too vague; “create a contact with the form answers, flag duplicate email addresses, and notify the sales owner” is something an agency can estimate and test.
Ask each agency to respond to the same brief. Require them to identify assumptions and exclusions rather than quietly filling gaps. If one proposal includes content migration and another assumes you will do it, their totals are not comparable.
Before you shortlist anyone, decide who on your side can approve design, content, and technical decisions. An agency cannot make up for a missing business owner. You do not need a large committee, but you do need one person who can resolve questions before they stall the build.
Inspect the portfolio for evidence, not resemblance
A portfolio shows what an agency is willing to display; it does not show what they built, how the site performs, or what happened after handoff. Ask for live projects comparable to yours, then have the agency explain its specific contribution and the constraints it worked under.
Do not limit “comparable” to your industry. A dental practice and a home-services company may have similar needs: local service pages, appointment requests, and staff-managed content. A beautiful direct-to-consumer store may be less relevant if your main problem is routing qualified leads to a small sales team.
For each shortlisted agency, examine a few live sites on your phone and desktop. Try the primary action. Read a service page. Look for broken layouts, confusing forms, missing confirmation messages, and content that appears difficult to update. A site may have changed since the agency delivered it, so treat what you see as a prompt for questions, not automatic proof of poor work.
Ask the agency to walk through one project from brief to launch:
- What did the client need the site to do?
- Which parts did your team design, develop, write, or integrate?
- What trade-offs did you make because of budget or time?
- How can the client update common content today?
- What broke during the project, and how did you resolve it?
- Who maintains the site now?
Request a reference you can speak with, ideally a client whose site has been live long enough to have needed routine changes. Ask that client what it is like to request an update, whether the final scope matched the proposal, and what they wish they had clarified before signing.
Be careful with performance claims that have no baseline or attribution. “We increased leads” is difficult to evaluate without knowing what changed in the offer, traffic, tracking, and follow-up process. You are looking for an agency that can explain decisions and limits, not one with the most impressive-sounding case study.
Test technical fit against your real workflows
The right technical stack is the one your business can operate, secure, and extend—not the newest framework in the proposal. Ask an agency to demonstrate how its recommended platform handles your content, integrations, ownership, and failure cases before accepting a build approach.
You do not need to dictate the CMS or hosting provider if you lack a strong reason. You do need clear answers to these questions:
- What can our team edit? Ask to see the editing experience for a service page, staff profile, price description, or whatever changes regularly in your business.
- Who owns the accounts? Your business should control its domain registration, hosting or platform account, analytics, and third-party subscriptions. The agency can have appropriate access without being the sole account owner.
- How do integrations work? Distinguish a native integration from a plugin, automation platform, or custom API connection. Each has different maintenance and failure points.
- What happens when a connected system is unavailable? A form that displays “Success” while silently losing a lead is not a working integration.
- How do we leave? Ask what content, code, data, and documentation you can export, and what would be required to move to another provider.
For a lead form, request a short delivery diagram or written flow: browser submission → validation → spam handling → CRM or inbox → confirmation → error logging. Ask where personally identifiable information is stored, who can access it, and how access is removed when staff or vendors leave. Avoid sending sensitive form data to tools simply because they are convenient.
Make testing concrete. A useful acceptance test might read:
Submit a quote request with all required fields. Confirm that the visitor sees a confirmation, the correct team receives the request, and the CRM record contains the submitted details. Repeat with the CRM unavailable and confirm the request is recoverable.
That second sentence separates a demo from an operational website. The same principle applies to booking, payments, email subscriptions, and AI-assisted workflows: test both the normal path and the failure path. If an agency proposes an AI agent to handle incoming leads, establish whether it drafts a response for review or can send one without approval. Those are materially different permissions. Our post on Gmail Inbox Router: Every Decision Gets a Receipt explores why a visible record of routing decisions matters.
Require an accessibility process you can verify
Accessibility should be part of design, development, content, and acceptance testing—not an optional plugin added before launch. Ask the agency which standard it works toward, what it tests manually, and how it fixes issues found after release.
The W3C Web Content Accessibility Guidelines (WCAG) 2.2 organizes its guidance around four principles: “Perceivable,” “Operable,” “Understandable,” and “Robust.” Those are useful requirements to discuss with an agency, but a claim of “WCAG compliant” means little without a stated target, testing approach, and list of known exceptions.
Ask the agency to show you how it checks the actual components your visitors will use:
- Can someone navigate menus, forms, and dialogs with a keyboard?
- Is keyboard focus visible, and does it move in a sensible order?
- Are form fields labeled and errors explained in text?
- Do images that convey information have appropriate alternatives?
- Is text readable at different screen sizes and zoom levels?
- Do videos need captions or transcripts?
- Can a person complete the primary conversion path using assistive technology?
Automated scans can catch some issues, but they cannot determine whether instructions make sense or a booking flow is usable. Ask for manual testing of your most important journeys and for a way to report defects after launch. Decide in the contract who fixes accessibility issues in the agreed scope and how those fixes are prioritized.
Accessibility obligations depend on your location, business, and circumstances. If you need advice about a legal requirement, consult a qualified professional rather than treating an agency’s sales claim as legal guidance. As a practical purchasing decision, you can still require accessible work and evidence of testing regardless of which rules apply to you.
Compare proposals by scope, ownership, and change rules
A price is meaningful only alongside the work, assumptions, and ongoing obligations it covers. Ask every agency for a written breakdown of deliverables, responsibilities, acceptance criteria, exclusions, and recurring costs; then compare proposals line by line.
A proposal should state who provides copy and images, who enters and reviews content, which pages or templates are included, which integrations are configured, and what constitutes completion. “SEO included” needs similar unpacking: does it mean editable titles and descriptions, redirects for old URLs, technical checks, content planning, or something else?
Use a comparison sheet like this instead of choosing on the headline total:
| Decision point | What to find in the proposal |
|---|---|
| Build scope | Named pages or templates, features, integrations, and migration work |
| Content | Who writes, supplies, enters, and approves it |
| Quality checks | Browser, device, accessibility, and workflow testing |
| Ownership | Domain, accounts, code or platform access, and export rights |
| Launch | Redirects, analytics checks, backups where applicable, and rollback plan |
| After launch | Support period, response process, maintenance responsibilities |
| Changes | How new requests are estimated and approved |
| Ongoing costs | Hosting, licenses, subscriptions, and support billed separately |
Ask what would trigger a change order. A new feature is an obvious example; an unclear brief that leads to extra work is a less pleasant one. A good agency will document its assumptions early and tell you when a request changes the agreed scope.
Clarify payment milestones and what you receive at each one. Avoid a final milestone defined solely as “site launched” if you have not agreed on tests for forms, analytics, redirects, editing access, and integrations. Likewise, do not demand endless revisions under a fixed fee; define review rounds and an approval process that both sides can follow.
Check the current pricing pages for any third-party platforms or services named in the proposal. The agency’s build fee may be a one-time cost while hosting, plugins, automation tools, and support continue after launch. You want the cost of operating the website, not just the cost of unveiling it.
Plan the handoff before the project starts
Post-launch support is a purchasing criterion, not a detail to negotiate when something breaks. Agree before signing on who monitors the site, who can make changes, how incidents are reported, and what documentation your team will receive.
Ask for a launch checklist tied to your business workflows. It should cover the primary visitor journeys; form destinations; booking or payment connections; analytics events your team will actually use; redirects from important old URLs; and access to the accounts you own. If the agency is replacing a site, ask how it will identify existing pages that need to remain available or redirect. A good-looking launch can still interrupt lead flow if a form points to the wrong destination.
The handoff should include a short walkthrough of routine tasks. Have the person who will maintain the site update a page, replace an image, inspect a form submission, and request support while the agency is available to answer questions. Written instructions or a recorded walkthrough are more useful than a meeting nobody can refer back to.
Establish an issue process with clear examples. A broken lead form is not the same as a request to change a heading. Ask where defects are reported, who acknowledges them, and how urgent issues are distinguished from planned improvements. If you are buying a maintenance plan, identify exactly what it includes: platform updates, backups, security review, content edits, integration checks, or only access to a support queue.
Finally, ask for a recovery plan. If an update breaks the site or a connected SaaS tool changes its API, who investigates? Is there a backup or rollback option? Who receives alerts, and can your team see them? You do not need an elaborate operations department for a small-business website, but you do need a named owner for problems that affect customers.
A strong agency will welcome these questions. It may not offer every service in-house, and that is fine if responsibilities are explicit. The warning sign is not “we don’t do that”; it is “don’t worry about that” when the issue determines whether the website works for your business.
How BizFlowAI approaches this
We build and run business workflow automations, so we start website discussions at the handoff points: where a lead goes, which system records it, who can act on it, and how the team knows when something fails. That framing helps a business specify what its website agency needs to deliver, even when the agency handles the design and site build.
A website should not become a separate island of forms and notifications. Define the workflow and its test cases first; then choose an agency that can build the front end, connect it to your existing systems, and leave your team able to operate it.
Work with BizFlowAI
If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.
Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.
More guides like this on the BizFlowAI blog.
Frequently asked questions
What should I put in a brief before asking web agencies for quotes?
Describe what visitors need to do on the site and what must happen after each action. List your existing systems, content to migrate, editing needs, and launch priorities. Give every agency the same brief and ask them to state their assumptions and exclusions so you can compare quotes fairly.
How can I tell whether an agency's portfolio is relevant to my website?
Look for live projects with workflows similar to yours, even if the clients are in different industries. Test the main action on both phone and desktop, then ask what the agency actually built and how the client updates it. Speak with a past client about changes after launch and whether the delivered scope matched the proposal.
What should I ask an agency about CRM and booking integrations?
Ask for a written flow showing where submissions go, who receives them, and how visitors get confirmation. Find out whether each connection is native, plugin-based, automated, or custom, and who will maintain it. Require a test of what happens when the CRM or booking system is unavailable so requests are not silently lost.
Who should own the domain, hosting, and website accounts?
Your business should control the domain registration, hosting or platform account, analytics, and third-party subscriptions. The agency can have the access it needs without being the sole account owner. Before signing, ask what code, content, data, and documentation you can export if you change providers.
How do I verify a web agency's accessibility claims?
Ask which accessibility standard and target the agency uses, what it tests manually, and how it handles defects after launch. Have it demonstrate keyboard navigation, visible focus, labeled forms, clear errors, and the primary conversion journey with assistive technology. Put responsibility for fixing issues within the agreed scope in the contract.