How to Evaluate an Agency's Work

A website agency can show you elegant screenshots, enthusiastic testimonials, and a list of impressive-sounding services. Those materials tell you what the provider wants you to notice. They do not tell you everything a customer can actually do on the finished websites.

That distinction matters whether you are comparing providers in Van Buren, Fort Smith, or Sallisaw. You do not need to become a programmer to examine useful evidence. You do need to know what to look for, what to ask, and where to stop short of conclusions the evidence cannot support.

This chapter is an investigation guide, not a ranking of local agencies. All business situations below are hypothetical. No individual agency or freelancer is being evaluated or accused here.

The three rules: No unsupported factual claims. No advertising disguised as education. No unnecessary technical complexity.

In this chapter

• A Personal Opinion From the Author

• What a portfolio actually proves

• Visit the live websites

• Recognize visual and usability problems

• Test mobile usability

• Check performance without worshipping scores

• Check accessibility for real people

• Examine the provider's own website

• Read public reviews critically

• Read responses to criticism

• Look for meaningful maintenance

• Decide whether case studies prove anything

• Check SEO and security claims

• Follow the 12-step investigation

• Compare the evidence and decide

• Final thoughts: evidence before advertising

A Personal Opinion From the Author

"You are going to choose the design you like best, and that is fine. However, if you are not satisfied with a product, you have the power to keep it from launching. Do not settle for less; deploy something truly remarkable. There is no perfect website, but there are definitely bad ones."

Personal opinion of the author, Joplin Solutions, 2026.

This is the author's advice about design preferences and accepting work. Agree in writing on approval milestones, acceptance criteria, and who can authorize launch. Check those terms before assuming you can withhold approval or payment without contractual consequences.

What a Portfolio Actually Proves

A portfolio is selected by the person selling you a service. Naturally, it usually displays work they consider successful. It can show experience, visual range, and examples worth exploring. It is not a random sample of every project, an independent audit, or a guarantee about your own future results.

Learn to separate six kinds of evidence:

1. A screenshot or mockup shows an appearance at one moment. It cannot establish whether buttons, forms, or mobile layouts work.
2. A staging demo may be a functioning prototype, but it may not have the same content, hosting, integrations, or conditions as the released site.
3. A live customer site permits direct observation. Its current condition may have changed since delivery.
4. A case study describes a problem, solution, and claimed result. The quality of its evidence depends on how specific and verifiable those claims are.
5. A custom-built project may involve original design or software. Ask which components were actually designed or developed, rather than assuming that the word custom describes every element.
6. An independently supported outcome has an identifiable measurement, period, method, and source. “More engagement” without a definition is not such an outcome.

A well-configured template or site builder can produce a perfectly suitable business website. Using one is not a defect, and original code is not automatically superior. The useful question is whether the provider accurately describes the work and delivers the functionality, quality, and ownership promised.

Consider your own requirements. A restaurant needs readable menus and clear booking information. A retailer needs findable products and a usable purchasing path. A contractor needs service areas, clear contact options, and convincing work examples. An impressive animation that gets in the way of these tasks is not necessarily an improvement. Research on website credibility emphasizes organization, useful disclosure, accurate content, and the ability to evaluate a business beyond its own promotional statements.^[1]

Ask for three or more relevant examples, including at least one recent one if the provider advertises recent work. Look for differences in business type and complexity. If every page has the same composition, that may be a deliberate product offering rather than a problem; ask how much customization the client receives. If only screenshots are available, ask whether live demonstrations, reference calls, or a walkthrough are possible. Client confidentiality or discontinued projects may explain missing live links.

Visit the Live Websites

Open several portfolio projects in separate browser tabs. Begin with an ordinary visitor's task, not an inspection tool. Imagine you know nothing about the business. Can you find the phone number, hours, services, pricing or request process, and any other essential information?

Then navigate like a real customer:

• Open the home page, one interior information page, and a page involving an action, such as contact, booking, or shopping.
• Use the main menu and footer. Follow public links to see whether they lead to the destinations promised.
• Open a product or service description and check whether the content answers a real customer's question.
• Look for missing images, overlapping text, template filler, confusing page titles, and empty sections.
• Repeat on your phone and a computer, if available. Try more than one portfolio project.

Do not interfere with operations. Avoid submitting fake inquiries, placing orders, testing payment credentials, generating unwanted reservations, or deliberately overwhelming a website. A public form can be inspected for labels and instructions without sending a fabricated request. If you are the actual client, arrange an approved end-to-end test using agreed test accounts or a staging environment.

Make notes about what happened, not what you imagine caused it. “The Services link led to a 404 page at 2:15 p.m. on October 29” is an observation. “The agency never checks its work” is an unsupported explanation. A missing page may result from a later client edit, a changed URL, an expired integration, or a temporary failure. If it matters, check again at another time and ask who currently operates the site.

A single strong site does not show consistency. A single bad visit does not demonstrate a pattern. Look across several projects and distinguish the provider's original scope from later client-controlled changes.

Recognize Visual and Usability Problems

You can notice many quality problems without knowing CSS or HTML. The key is to distinguish a choice you dislike from a barrier that prevents someone from using the website.

Oversized headings: impressive or obstructive?

Large headings can create an effective visual hierarchy. They are not inherently poor design. But ask whether the heading consumes the entire first screen while burying information visitors came to find. Watch for a headline that wraps into an awkward wall of words, clips at the edge, collides with a photograph, or covers a button on a narrow phone. Try increasing text size: does the headline adapt, or does content disappear?

Testable: text overlaps, is cut off, becomes unreadable, or hides a necessary control. Subjective: you would personally prefer smaller type. Heading size is not the same thing as heading structure: assistive technology also relies on meaningful headings organized by topic.^[2]

Broken layouts

Visible failures include text sitting on top of an image without enough contrast, buttons protruding from cards, pictures rendered in the wrong place, navigation covering the page, and unexplained empty blocks. A website that forces the entire page to scroll sideways on a phone deserves a closer look. So does a floating chat box that covers the checkout button.

Watch out for the opposite mistake: some things, including wide data tables, maps, and diagrams, legitimately require two-direction scrolling. WCAG's reflow requirement recognizes such exceptions; it does not mean every horizontal scrollbar is a violation.^[3]

Poor usability

Test whether menu labels match the destinations, buttons behave as labeled, content is searchable or findable, and important instructions make sense. Can someone return to the previous page? Are form fields clearly identified? Is an error explained in ordinary language? Is a dismissible banner actually dismissible? A beautiful contact form that prevents people from contacting a business is a business problem, not merely a design preference.

Watch for distracting auto-playing animation or moving elements that cannot be paused. People use websites with differing visual, motor, and cognitive needs; accessibility guidance addresses moving content and user control.^[4]

Inconsistent design and unfinished material

Inconsistent fonts, spacing, branding, buttons, imagery, and repeated decorative blocks can make a site feel assembled rather than designed for its specific business. But consistency is evaluated within a brand and project, not by a universal rule that every button must look identical. A purposeful secondary button is different from an unexplained collection of styles.

More concrete concerns include “Lorem ipsum,” stock-template instructions, sample products, missing image icons, placeholder phone numbers, contradictory hours, old “coming soon” notices, and footer links that lead nowhere. Look especially closely when these appear on several projects.

Record what you saw without assigning blame

Use a neutral note such as: “At a narrow phone width, the call button was partly hidden by the navigation panel; I observed the same result twice.” Then ask who built that component, whether the page changed since launch, and whether the current maintenance contract covers fixing it. Evidence that something is broken is not evidence of who broke it.

Test Mobile Usability

A desktop screenshot is a poor substitute for a real phone. On your device, try the site in portrait orientation, then landscape where supported. Tap the menu, select a service or product, scroll through longer pages, and open any public booking or cart entry point without completing an unnecessary transaction.

Use these questions as a practical test:

• Is the text readable without pinching or constantly zooming?
• Are tap targets separated enough to avoid accidental activation?
• Does the menu stay visible and usable without covering what you need?
• Do photos resize without hiding essential information?
• Are forms, search, carts, and booking links still usable?
• Can you reach the same important content available on desktop?
• Is the page free of unintended full-page sideways scrolling?
• When text is enlarged or the browser is zoomed, can you still complete the task?

WCAG 2.2 includes requirements concerning text resizing, reflow, and usable targets; these are more useful evaluation references than insisting that every design look identical at every screen width.^[5]

Optional advanced check: In Chrome on a desktop, open Developer Tools, enable the device toolbar, and try narrow viewport sizes. This is a helpful approximation, not a substitute for physical devices. Chrome explicitly warns that emulation cannot reproduce every aspect of mobile hardware or behavior.^[6]

Hypothetical Fort Smith example: A restaurant's agency portfolio shows an attractive desktop menu. On a phone, the menu's food descriptions are hidden behind a large decorative heading. You can fairly say that the observed mobile page is difficult to use. You cannot yet say who introduced the problem or whether the provider was contracted to update that menu.

Check Performance Without Worshipping Scores

A site can feel slow because content takes too long to appear, tapping causes a delay, or elements shift while someone tries to use them. Google tracks related aspects through Core Web Vitals: Largest Contentful Paint (LCP) for the appearance of the main content, Interaction to Next Paint (INP) for responsiveness to user interaction, and Cumulative Layout Shift (CLS) for unexpected visual movement.^[7]

Google's current “good” field thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, evaluated at the 75th percentile of real experiences. These thresholds are useful benchmarks, not guarantees that visitors will like or successfully use a site.^[8]

Run a PageSpeed Insights report

1. Open Google PageSpeed Insights.
2. Enter the public URL of a page you want to examine. A home page alone will not represent a product page, checkout flow, or complex contact page.
3. Review Mobile and Desktop separately.
4. First inspect real-user or field data, if available. It summarizes eligible Chrome user experiences over a preceding 28-day window; it is not a live speed test of every person.
5. Then inspect the lab results. Lighthouse runs an automated simulation and reports opportunities for investigation.
6. Check the actual explanations, such as oversized images, blocking resources, or layout shifts. Record the URL, date, device category, and relevant conditions.
7. Run the test more than once, preferably at different times, before drawing a conclusion.

PageSpeed Insights distinguishes field data from lab simulations because they answer different questions. A low-traffic URL may have no qualifying field dataset. A green lab score of 90 or more does not necessarily mean real users have good performance, and a single lab score can vary between runs.^[9]

How to read the result: If mobile lab performance is weak but field data is good, ask why the simulated run differs from normal traffic. If real-user LCP is poor across a substantial sample, it deserves attention. If the page visibly shifts while loading and CLS is elevated, those findings reinforce one another. Do not infer a cause from the colored circle alone.

The provider might have shipped an unnecessarily large image. Or the customer may have added a large video, third-party ad network, chat widget, or new plugin later. Hosting and network conditions can also change. The report describes the observed page and test conditions; it does not identify contractual responsibility.

A perfect performance score is not a certificate of accessibility, security, usability, or commercial success. Lighthouse's accessibility score uses automated audits; manual audits do not affect it.^[10] Use human evaluation alongside automated checks.^[11]

Check Accessibility for Real People

Accessibility asks whether people with different abilities can perceive content and use the controls necessary to complete tasks. This includes people navigating with a keyboard, screen reader, magnification, touch, voice input, or reduced-motion settings.

Try a few low-risk checks yourself:

• Keyboard: On a computer, press Tab repeatedly. Can you reach links and buttons, tell which item is selected, and leave open menus? A visible focus indicator is a WCAG requirement for keyboard-operable interfaces.^[12]
• Readability: Can you distinguish text from the background? Does text remain visible when enlarged? Are essential instructions communicated with more than color alone?
• Images: Does an image convey crucial information that is missing from adjacent text? Alternative text needs to communicate meaningful content, not simply list keywords.
• Forms: Are labels clear, required fields identified, and errors explained? Do not send bogus submissions to test a business's inbox.
• Motion and structure: Can distracting movement be paused where appropriate? Does the information follow a meaningful heading order? Can you read a page without using a mouse?

W3C's Easy Checks offer a beginner-friendly first review, covering titles, headings, alternative text, text contrast, resizing, keyboard access, and forms. They deliberately do not represent a complete accessibility evaluation.^[2]

Free or free-tier tools can help:

• WAVE identifies many likely issues on public pages and supports manual review; its browser extensions provide another inspection method.^[13]
• axe DevTools provides a free, page-by-page automated browser extension; more advanced guided and reporting features are paid.^[14]
• Lighthouse includes automated accessibility checks alongside performance diagnostics, but its accessibility result covers only the checks it runs.^[10]
• W3C's evaluation-tool guide helps explain why tools are aids to human judgment rather than proof.^[11]

Suppose an automated tool detects missing form labels. That is a concrete reason to investigate. Suppose a report finds zero errors. That does not establish that a screen-reader user can complete an order or that the site meets WCAG. W3C warns that no automated tool can determine all accessibility requirements and that false or misleading results are possible.^[11]

A serious accessibility evaluation combines automated checks with manual keyboard inspection, assistive technology use, and testing or review by people with disabilities. Ask what pages, user journeys, technology, and versions were tested, who conducted the evaluation, what was fixed, and which issues remain. WebAIM's large-scale research also explicitly cautions that an absence of automatically detected errors does not establish accessibility.^[15]

Legal distinction: WCAG is a technical standard, not a single universal verdict on legal compliance. U.S. ADA obligations differ by organization and circumstances. The Department of Justice distinguishes Title II state/local government obligations from Title III public accommodations; newer Title II web rules must not be casually applied to every private business. An automated warning is not, by itself, proof of an ADA violation.^[16]

Examine the Provider's Own Website

If a business sells websites, its own website is relevant evidence. It can show how the provider communicates services, organizes information, demonstrates accessibility priorities, and maintains a public presence.

Apply the same everyday tasks you used on the portfolio. Try mobile navigation, contact information, important service pages, loading performance, readable copy, keyboard access, and working links. Does the provider explain what it does without surrounding ordinary services with unexplained labels? Are “fast,” “accessible,” “secure,” and “custom” supported by clear scope or measurement?

Pay attention to a mismatch, not merely one imperfection. If a provider prominently claims to build fully accessible websites but cannot explain its accessibility process, that warrants questions. If its own important actions are repeatedly broken, that is a stronger concern than disliking its chosen color palette.

Still, the provider's site is a sample of one. Some teams devote different resources to internal marketing than to paid client projects. Its current content may be managed separately. Compare it with multiple live projects and ask for an explanation of relevant differences before deciding.

Read Public Reviews Critically

A five-star average tells you something about the reviews that were published. It does not tell you everything about technical quality, contract fulfillment, or every client's experience. The FTC specifically regulates certain fake reviews, undisclosed insider reviews, sentiment-conditioned incentives, and deceptive review-suppression practices. Those rules are reasons to treat review authenticity seriously, not grounds to accuse an agency merely because reviews look positive.^[17]

When reading reviews of a prospective provider, look beyond the average:

• Volume and recency: Are there enough accounts to suggest a range of experiences? Has the character of feedback changed over time?
• Specificity: Does a reviewer discuss actual deliverables, communication, timelines, handoff, or support, rather than offering only generic praise?
• Relevant service: Is the review about website work, or something unrelated that the same company also sells?
• Independence: Are details consistent across independent review locations, where those are available? Do not assume copied wording proves dishonesty.
• Recurring themes: Do distinct reviewers describe similar problems or strengths? Record the theme, dates, and context rather than treating repetition as a verdict.
• Response pattern: Does the business address specific concerns professionally? An answer is visible communication, not proof of resolution.

Review platforms have their own policies and moderation processes. Google, for example, provides business owners ways to reply and report policy-violating reviews.^[18] Google also explains that reviews can be delayed or removed. A missing review alone does not prove suppression.^[19]

The FTC's guidance to marketers discourages asking only likely-happy customers and stresses disclosures around personal or financial connections. These principles help explain why how reviews are gathered matters as much as their total count.^[20]

A detailed positive review about helpful training and reliable support is useful evidence of the reviewer's reported experience. It is not an independent code inspection. A negative review about a disputed final invoice may reflect a real disagreement but does not, by itself, settle what the contract required.

Read Responses to Criticism

A provider cannot control every complaint, but it can choose how it responds publicly. Read the interaction, not simply the reviewer's star rating.

Constructive signs may include acknowledging the concern without attacking the customer, explaining an appropriate next step, taking responsibility where justified, referring sensitive details to a private channel, and providing a realistic way to continue the discussion. Professional replies may reassure you that a process exists for disputes, even when the outcome remains private.

Patterns worth asking about include repeated insults, publishing a customer's private information, unrelated sales pitches in place of answers, reflexively blaming every customer, unsupported public allegations, or repeating a generic “we solved it” message without visible explanation. These are reasons to ask about communication and dispute handling, not proof of an unethical business model.

You can critique work without being a customer

"You do not need to be a paying customer to review the publicly visible work of an agency or freelancer. If you offer a critique and they become defensive or aggressive, do not let that reaction bully you into backing down. Form your own opinions and seek second opinions."

Personal opinion of the author.

Be clear that you are commenting on publicly visible work. Do not imply that you hired the provider or know the facts of a private client relationship.

What a public response cannot tell you

The reviewer may have omitted critical information. The company may have contractual privacy obligations. A provider may reasonably dispute a false claim or refuse to discuss payment details online. A brief reply can be prudent, and silence publicly does not show that no private conversation occurred.

Likewise, “Contact us and we'll make it right” does not establish that anything was fixed. Evaluate the tone and specificity of the response, then ask prospective providers about their actual escalation procedure: who receives a support request, how scope disputes are documented, when problems are prioritized, and what happens when buyer and seller disagree.

Hypothetical Sallisaw example: A contractor comparing agencies notices several dated complaints about slow replies. The agency answers some professionally but does not discuss private projects. The contractor should ask for support hours, response expectations, an escalation contact, and references. They should not publish the assertion that the agency ignores its clients.

When you notice recurring patterns, write down specific, dated observations instead of counting allegations as verified facts. You are evaluating whether the provider is an appropriate choice for your needs, not conducting a public trial.

Look for Meaningful Maintenance

An active-looking website can be neglected, and a quiet website can be well maintained. A business that updates its blog weekly could still have broken navigation. A developer that never blogs may still build excellent websites and keep client systems current.

Is the blog useful and accurate?

Start with its claimed purpose. If a provider says its blog delivers current SEO, accessibility, or development guidance, open a recent post and an older popular one. Do examples still match the software being described? Do outbound references work? Are standards and services represented accurately? Has an article been revised where its advice became obsolete?

A publication date answers when something was reportedly published. A revision date claims it was changed. Neither proves how carefully it was reviewed. Search engines themselves use several signals to estimate publication and significant-update dates because no single visible or technical date is conclusive.^[21]

A copyright notice that changes from one year to the next is trivial evidence. A sitemap lastmod value is a useful declaration but not independent confirmation of a content rewrite. Google instructs site operators to use it for significant changes, not merely updated copyright text.^[22]

An old article that is still accurate can remain valuable. A newly dated article containing outdated instructions can be misleading. Focus on accuracy, relevance, and the specific promises the provider makes, not an arbitrary posting schedule.

Compare public versions carefully

If an archived snapshot is available through a public web archive, comparing its visible text and layout with today's version can sometimes reveal changes. Archive captures are incomplete historical observations, not a full change log: a missing snapshot may reflect a crawler's limitations, blocked content, or the archive's coverage. Do not conclude that no update occurred merely because you cannot see one.

If a client site or portfolio entry looks abandoned, confirm that it still exists and that its links work. Ask whether the provider's role ended at launch, whether the customer later took over the account, or whether an older project is intentionally shown as historical work. A project may have changed owners, platforms, or domains.

Maintenance is usually private evidence

A support contract may include backup checks, software updates, monitoring, restoration drills, or security review without generating a public blog post. If a provider sells ongoing maintenance, ask what tasks are included, who performs them, how often, and what report or record a paying customer receives. A redacted sample maintenance report or description of incident handling may be more useful than a frequently refreshed homepage.

Do not infer the absence of private work from the absence of public posts. Equally, do not accept a new date as proof that promised maintenance was done.

Decide Whether Case Studies Prove Anything

Case studies are most useful when they follow a recognizable chain: the client's goal → the original problem → the work performed → how success was measured → the limits of the result.

A credible study might explain that a retailer needed a product catalog that worked on phones; the provider reorganized categories, simplified product selection, and conducted user testing. If the provider claims purchases increased, it should identify the period, comparison, measurement source, and other relevant changes. “Engagement improved” without saying whether engagement means clicks, session length, inquiries, or sales is too vague to independently evaluate.

Also ask: Did the agency design the layout, supply content, install and configure a purchased template, build custom integrations, run accessibility tests, operate hosting, or simply consult? Each can be legitimate work, but they are different services.

Confidentiality may prevent sharing actual revenue, account access, contract terms, or customer names. Respect that. A provider may instead offer anonymized methods, redacted sample reports, an authorized client reference, or a demonstration with clearly stated limitations.

Do not demand private analytics from unrelated businesses. If the result cannot be independently checked, label it a provider-reported claim, not a proven outcome. Ask what evidence you would receive if you purchased a similar service.

Check SEO and Security Claims

What “SEO optimized” can reasonably mean

You can publicly inspect whether page titles describe their pages, menus and links lead to useful content, headings reflect the page's subject, URLs are understandable, and pages appear to provide genuine information. Google's SEO Starter Guide supports useful site organization and descriptive URLs, not a secret trick that guarantees top rankings.^[23]

Some issues, including obviously broken public navigation, can be seen without tools. Others require technical inspection: whether crawlers may access a page, whether important pages are indexed, whether canonical signals point correctly, and whether structured data describes content accurately. Structured data can make a page eligible for certain search features, but Google does not guarantee those features will appear.^[24]

A public search can suggest whether a page appears in Google, but an omitted result from one query does not prove that a page cannot be indexed. Use the site's authorized Google Search Console access to inspect search traffic, indexing problems, and related diagnostics. Ask for permission-based, appropriately redacted reports if an SEO campaign's success is part of the sales claim.^[25]

Technical SEO hygiene is not proof of revenue growth. A provider can correctly implement titles and canonical tags without controlling customer demand, competitors, or the business's sales process. Chapter 6 addresses the broader SEO sales pitch; here the question is what evidence supports this specific provider's work.

What “secure website” can reasonably mean

A website using HTTPS helps encrypt communications in transit,^[26] but a padlock alone cannot tell you whether its login system, dependencies, permissions, or backups are properly managed. OWASP's current Top 10:2025 highlights categories including broken access control, misconfiguration, software supply-chain failures, cryptographic failures, and authentication failures. These risks cannot be dismissed merely because a website loads over HTTPS.^[27]

Do not try to break into another business's website. Do not probe login protections, guess credentials, run intrusive scanners, or attempt to uncover private data without authorization.

Instead, ask the provider how it handles administrative access, multifactor authentication where available, software updates, backups, restoration, incidents, and secure handoff when the contract ends. The FTC recommends practical protections such as multifactor authentication and regular software updates; security due diligence should consider ongoing operations, not a one-time sales badge.^[28]

For a project handling sensitive customer information or payments, request a clear description of who operates which parts of the system and which third-party services are involved. For complex or high-risk work, arrange authorized independent security review. No automated “all clear” can establish that a site is hack-proof.

Follow the 12-Step Investigation

You can complete a useful first pass with a phone, a computer if available, a browser, and a notebook. Take the same steps for each provider so that your comparison is reasonably fair. The tasks below focus on public, nonintrusive observations.

1. Start with the provider's own site. Find services, location or service area where relevant, contact options, and claims. Record: clarity and any specific promise you intend to check. Limit: the agency's site is only one project.
2. Collect several portfolio examples. Choose relevant business types, not just the prettiest home pages. Record: live URLs versus mockups and dates if shown. Limit: portfolio examples are curated.
3. Open the live projects. Visit home and interior pages. Record: what a visitor can actually reach. Limit: today's site may differ from the handoff version.
4. Use a real phone. Test menus, text, images, and touch controls. Record: tasks completed and barriers. Limit: your phone is not every user's device.
5. Check major actions safely. Follow public links and inspect instructions without sending fake inquiries or transactions. Record: dead ends, errors, and accessible alternatives. Limit: do not infer back-end behavior or contract responsibility.
6. Review content and maintenance clues. Look for placeholders, obsolete instructions, dates, and working citations. Record: exact examples. Limit: an old date is not proof of neglect.
7. Run PageSpeed Insights. Test relevant URLs on mobile and desktop; compare field and lab data if available. Record: date, device category, metrics, and repeated results. Limit: one score is not the full user experience.^[9]
8. Perform introductory accessibility checks. Try keyboard navigation, zoom, W3C Easy Checks, and a tool such as WAVE or axe. Record: barriers and which method detected them. Limit: this is not a complete audit or legal finding.^[11]
9. Read public reviews. Compare specificity, dates, and relevance. Record: themes, not just stars. Limit: reviews describe reported experiences, not independently established facts.
10. Read responses to criticism. Notice professionalism, proposed next steps, and patterns. Record: observable public behavior. Limit: you cannot see private resolution.
11. Match promises to evidence. For “custom,” ask what was custom; for “fast,” ask which pages and conditions; for “accessible,” ask what was tested; for “SEO,” ask how results were measured. Record: claims supported, unresolved, or contradicted by observed facts. Limit: some legitimate evidence is private.
12. Ask the provider to resolve open questions. Present neutral observations and request scope, support, and measurement details. Record: the response and any documented commitments. Limit: even good evidence cannot guarantee future performance.

Your comparison sheet

Hypothetical Van Buren example: A retailer comparing two ecommerce proposals visits each provider's live portfolio. One has attractive desktop shots but a cumbersome mobile product selector; the other uses a simpler design with clearer mobile product information. The retailer records both experiences, asks for an approved checkout demonstration, and compares who owns the catalog and who supports it. Neither appearance nor the present state of a third-party client site settles the decision alone.

Keep a small, fair evidence log

For anything significant, write down the URL, date and time, device/browser, exact steps, what you saw, whether it happened again, and what the provider said when asked. Save private notes or permitted screenshots for your own decision-making. Do not publish identifying defect collections or other people's private information. Compare projects fairly: checking three complex ecommerce websites against three static brochure websites tells you something about the different scopes, not necessarily about equivalent ability.

Compare the Evidence and Decide

Do not invent an agency score out of ten. Quality is not a single number, and a score would hide the differences that matter most to your business.

Positive evidence includes several usable projects, a clear description of work performed, an honest explanation of testing and limitations, appropriate references or documentation, defined handoff and support responsibilities, and direct answers to reasonable concerns.

Issues to clarify include old or inaccessible portfolio links, inconsistent performance, undocumented accessibility testing, unclear maintenance terms, unexplained pricing, a claim that cannot be checked publicly, and mixed reviews. These may have ordinary explanations, but explanations should be specific enough to evaluate.

Serious concerns may arise from repeatedly observed failures in essential functions, materially contradictory representations that the provider cannot explain, refusal to define ownership or critical contractual responsibilities, or clearly documented abusive public conduct. Do not call a representation “false” unless the contradiction is actually established. A hostile-sounding review does not establish fraud, and one broken customer page does not establish that the agency delivered defective work.

Try these questions before signing:

• Which parts of the project will be custom designed, configured from a template, licensed, or provided by outside services?
• Can you show a relevant project on mobile and explain what your team was responsible for at delivery?
• What accessibility standards and manual tests do you use, and which user journeys do you evaluate?
• How do you measure performance, and how do you treat third-party integrations?
• If you promise SEO results, what specific work and measurable reporting will I receive?
• Who owns the domain, content, accounts, design assets, and exportable website materials when the project ends?
• Who maintains the site, handles backups, applies updates, responds to incidents, and repairs problems after launch?
• What happens when we disagree about scope or when a defect is reported?

A provider that charges more may be worth it because of credible expertise, specialized work, reliable operations, and better support. A lower-cost builder or freelancer may be appropriate if the requirements are simpler. The question is not whether an agency looks expensive or fashionable. It is whether its documented work and responsibilities fit your needs.

Final Thoughts: Evidence Before Advertising

A professional-looking portfolio creates a first impression. A live website lets you test the experience. A well-explained case study helps you judge the work behind a claim. Public reviews may suggest how customers experienced a project, and responses to criticism can show how a provider communicates under pressure. None of those observations should be stretched beyond what they support.

Use several independent kinds of evidence. Take notes. Recheck important defects. Give the provider an opportunity to explain scope and history. Respect client privacy and the distinction between original development and ongoing maintenance.

The point is not to catch an agency making a mistake. It is to make a hiring decision based on what you can verify, what remains uncertain, and what your contract actually promises.

Before you hire a web designer, read this. And then inspect the work for yourself.