What to inspect before sending a website to the client

There is a moment in every project when the client's relationship to the site flips. Before the first "finished" link, they read everything as progress. After it, they read everything as a mistake hunt — and the first defect they personally discover costs more trust than ten you disclose yourself.

Which makes the hour before that email the highest-leverage QA hour in the project. Not a full launch review — the site is not launching yet — but a disciplined pass over exactly the things a client meets in their first ten minutes.

Freeze what you are about to send

Same rule as a launch review, smaller scale: the link you send is a specific deployment, and after you hit send, it does not move. A client who refreshes mid-deploy and meets a broken build has, from their side, simply seen your work be broken. If the site must keep changing, send a pinned preview URL instead of the live staging root.

Walk the client's path, not yours

You open the site to the pages you built most recently. The client opens it the way a stranger would — and they will do it on their phone, probably in the elevator after your email arrives.

So walk that path deliberately, on a real phone, before they do:

The last row earns its place: recent work gets recent attention, so the stale defect is usually sitting on a page nobody has opened in three weeks.

Read the words they will read first

The client will not diff your CSS. They will read their own company's name, their title, their product's price, and the sentence describing what they do. An error in any of those reads as you not knowing their business — which is a different and worse category than a bug.

Names spelled right. Titles current. Prices actual. Placeholder copy gone — searched for, not skimmed for: lorem, TODO, TBD, xxx, and the template's default tagline, checked in the page source rather than by eye.

Test the things that answer back

Anything interactive answers the client's unspoken question — does this actually work? — one way or the other.

• Forms: submit every one, confirm where the submission arrived, and check the failure state by submitting with the network cut.
• Links: click the navigation and the footer. For anything returning 401/403, sign in and confirm it — a protected route is not broken, but you want to be the one who says so first, with evidence.
• The share preview: paste the link into a chat app before the client does. The Open Graph card — image, title, description — is the first thing their partner or boss sees. A missing card image is invisible in the browser and glaring in the group chat.

Inspection ticket№ AP-2026-9162

High priorityConversion

Share preview shows the framework default card

FILED ON · /

Pasting the staging URL into a chat client renders the boilerplate site name and a grey placeholder. Evidence: preview capture, 24 July. Fix before the client shares the link — this is the version of the site most of their colleagues will ever see.

The basics, at handoff depth

Privacy, accessibility and performance get their full treatment at launch; at handoff, check the three things a client can trip over unaided: the site does not horizontally scroll on a phone, text over images stays readable, and the heaviest page loads acceptably on mobile data. Anything deeper is launch review work — noting that boundary in the handoff email is itself a professionalism signal.

Decide what is a blocker — before sending

Whatever you find in this hour goes in one of two piles: blocks the email, or ships with a note. The discipline is deciding by the client's consequences, not by your embarrassment. A typo in their CEO's name blocks. An unpolished hover state does not — it goes in the note.

Send the note with the link

The handoff email is a miniature of the launch report: what this link is, what was verified, what is known and owned, and what you need from them. Five sentences, not a document.

Here is the preview: [link]. This build is frozen — nothing changes on it without telling you. We verified the customer journey, forms and share previews on desktop and phone this morning. Two known items ship with it: the team bios await your final text, and the case-study images are placeholders until Friday. What we need from you: confirm the pricing table matches the sheet you sent on the 12th.

A client who receives that email starts their review inside your frame: verified, known, needed. A client who receives a bare link builds their own frame — and theirs is a mistake hunt.

Record what you verified

Last, thirty seconds for your own protection: a line in the project channel recording what was checked, on which build, by whom. When feedback arrives claiming "the form never worked", the difference between an argument and a calm reply is that line.