Case study · Client review
Website feedback usually arrives as a list of sentences about a page nobody is looking at together. “The bit under the header, on the services one, is too long.” Rebuilding what someone meant is slower than the edit, and it is where meaning goes missing. So the review happens on the site itself: the client opens the real pages, leaves a note on the thing they are talking about, and the work continues without a meeting to decode it.
The problem
A site in progress needs the client's judgement on things only they can settle: whether the wording is how they speak, whether a claim is one their business can stand behind, whether a photograph is current. None of that is design review. It is the part of the work that cannot be done for them.
The constraint was time, not willingness. An operator's day does not hold a scheduled walkthrough, and a draft that is only reviewable while someone is on a call gets reviewed once and approved out of politeness. What was needed was a way for them to look at it whenever the hour arrived, say what they meant where they meant it, and have that be enough.
What was built
The draft is not public. A shared code opens the door and sets an expiring cookie, and every response carries instructions to stay out of search indexes and out of caches. Reading or writing a single note then requires signing in with a work account, verified against the identity provider's own keys and checked against an allowed domain.
A note is anchored to the element it was left on, not to a page name and a paragraph number. Reopening the page puts it back where it was written. That is the whole point: the sentence and the thing it refers to arrive together.
Notes take replies, so a question gets an answer in the place it was asked. A note can be taken back when it turns out to be wrong, rather than deleted quietly or left standing as a decision nobody meant to make.
A half-written note is kept on the device and synchronised when it can be. The people using this are working between other things, and losing a thought to a closed tab teaches them not to bother next time.
How it stays safe
The overlay and its routes live alongside the site, not inside the pages it reviews. The published site is built from source into a directory of plain files, exactly as it will be served, so what the client is marking up is the artefact and not an approximation of it.
Notes are stored server-side in their own database, reached only through those routes, each of which checks the code, the session and the account before it does anything. Nothing about the review survives into the site that eventually goes live: when the draft is published, the gate, the overlay and the notes stay behind.
What is not claimed
The client is not named and the draft is not linked. It is a private preview behind the gate described above, and it stays that way until they decide otherwise. No note content, reviewer name or address appears here.
This is a working arrangement on one engagement, not a product. It has not been hardened for other people's sites, sold, or run at any scale beyond the job it was written for. What it demonstrates is the method: put the conversation on the artefact, and let the other person choose the hour.
Let’s talk