Internal review and QA before a client sees the site

Internal review and QA is the supplier checking their own finished work against a defined fault list before the client is shown the site for approval. It is a distinct, earlier stage than client testing, and the distinction matters: this is quality control performed by the people who built the site, on their own work, before anyone outside the project sees it.

What it actually checks

Check	What it catches
Every link	Broken links, links pointing to the wrong page, or links left pointing at placeholder addresses
Forms	Whether submissions actually arrive where they are meant to, and whether validation messages work
Responsive behaviour	Layout problems on phone and tablet screen sizes, not just the desktop view used during design
Cross-browser rendering	Differences between how major browsers display the same page
Spelling and basic content errors	Typos and formatting mistakes introduced during population
Page load speed	Obvious performance problems before they reach a client or a live visitor
Basic accessibility	Keyboard operation, image alternative text, and heading structure, at minimum

None of this is exotic or specialised testing — it is a checklist applied systematically, which is precisely why skipping it under time pressure is so easy to justify in the moment and so costly afterwards.

Why this is a genuinely separate stage from client testing

A client testing a site for the first time is evaluating whether it does what was agreed — the business-level question. A supplier’s internal review is evaluating whether the thing that was built actually works as built, technically — the engineering-level question. Conflating the two, by skipping internal review and treating the client’s own testing as the first real check, means the client is doing quality assurance work they were not asked to do and are not necessarily equipped to do systematically. A client is very good at judging whether a page reads correctly and looks right for their business. A client is not the right person to be the first to discover that the contact form silently fails on a particular phone’s browser.

What skipping this stage looks like, and why it happens

The candid version: internal review takes real time and produces nothing new to show the client — it is checking work that is already, in the supplier’s view, finished. Under deadline pressure, it is the stage most likely to be compressed or skipped, because unlike a missed design deadline, a skipped QA pass is invisible until something breaks. A supplier who has never talked about how they QA a build, unprompted, may not be running this stage with any real rigour — it is a fair, direct question to ask before a project reaches this point: what does your team check before I ever see the finished site.

Accessibility, specifically, at this stage

Basic accessibility checks belong in internal review because they are exactly the kind of systematic, checklist-driven work this stage exists for — keyboard operability, alternative text on meaningful images, and a logical heading structure, at minimum. This is not the same as a full accessibility audit, and an automated scan alone does not substitute for it either; a large share of accessibility criteria require human judgement that a scan cannot make. If accessibility is a live concern for a particular project or industry, a structured self-assessment such as the one on this site’s accessibility self-assessment tool is a reasonable next step, separate from and beyond what a standard internal QA pass covers.

What a client can reasonably ask about this stage

Before a project reaches the point of being shown to the client, it is fair to ask: is there a documented internal check before I see this, and what does it cover; has the site been checked on an actual phone, not just a resized browser window on a desktop; and were the forms tested with a real submission, not just visually inspected. A supplier with a genuine process will answer these specifically, because the process already exists and does not need to be invented on the spot.

Why a checklist beats memory, even for an experienced team

An experienced developer can genuinely believe they have checked everything relevant on a site they built themselves, simply because they know it so well — and still miss something a written checklist would have caught, precisely because familiarity makes it easy to skip past a step mentally rather than actually performing it. This is not a comment on any individual’s competence; it is a well-established limitation of relying on memory for repetitive checks, and it is the reason a written, followed checklist consistently outperforms an experienced person’s unaided judgement, on this task as on many others. A supplier who can show, rather than describe, the checklist they actually use is demonstrating something more concrete than a supplier who simply says “we’re thorough.”

Testing on the actual devices customers use

A page that looks correct on a large desktop monitor can behave differently on the specific, older phone model a real customer is holding, with a smaller screen, a slower connection, and a different browser version than whatever was used to build the site. Testing on an actual phone, not a resized desktop browser window simulating one, catches problems that simulation alone does not — a button that is technically present but too small to tap accurately, or a menu that opens correctly with a mouse click but behaves differently with a finger tap. This distinction is worth asking about directly: was this tested on a real device, not just a resized window.

Where this sits in the sequence

Internal review and QA is the last checkpoint before the client is formally asked to test and approve the finished site. See client user acceptance testing for what happens next, and why that stage checks a different thing again — whether the finished site, already technically sound by this point, actually satisfies what the client originally asked for.