How to review a web app (your pass, then the client's)
To review a web app before handing it to a client, do two passes: your own (error states, empty states, copy, broken flows at the edges) and then the client's (share a link they can annotate directly on the live app — no account, no extension). The single most expensive mistake is skipping your pass and sending a staging URL cold. The client finds the empty state that shows a raw error code. You spend the first round on things you would have caught.
Check the states that only appear at the edges
Most web apps look fine on the happy path. The review-worthwhile gaps are in the states designers and developers stop testing once the main flow works: the empty state before any data exists, the error message when a form submission fails, the loading state on a slow connection, the logged-out view someone lands on after a session expires. Open the app and deliberately break it — submit the form with a bad email address, clear your account data so the dashboard is empty, throttle your network to 3G in DevTools (Network → Throttling). What a client sees when something goes wrong tells them whether the product feels finished or half-built. An empty state that shows a blank white screen or a raw database error costs more trust than any visual polish earns back. Log every state that reveals something unfinished as a fix, not a note — repair it before the client link goes out.
Walk every primary flow as if you have no context
You built it. You know that the export button is in the overflow menu, that the setup wizard appears only on first login, that the confirmation email takes 30 seconds. Your client does not. Before sending a review link, do one cold walk of the primary flow: close the browser, open a private/incognito tab, and proceed from the entry point to the goal — signup, onboarding, and the first meaningful action. Write down every moment where you relied on knowledge the client won't have. Nav labels that made sense in your head but aren't obvious out of context — those need to be flagged or fixed before review. The most common source of multi-round client feedback is a confused user who doesn't say 'the label on step 2 isn't clear' but instead says 'I couldn't figure out how to get started' — which produces an email exchange instead of a specific fix. Your cold walk is the round you don't pay for in revision cycles.
Audit the copy before any human reads it
Copy issues look like UX problems in client feedback. 'It feels unprofessional' often means a form label is truncated on mobile, an error message says 'Something went wrong (code 400)', or a button says 'Submit' where it should say 'Save changes.' Run a quick copy pass: every button label, every error message, every empty state heading, every email subject line triggered by user action. Check them at mobile width (375px) — labels that look fine at desktop often truncate or wrap in ways that change meaning. Particular gotchas: destructive actions with no confirmation prompt, modals whose headline doesn't match what they actually do, and loading indicators with no text for screen-reader users. A copy pass takes 15–20 minutes. The round of feedback it prevents typically takes two days.
Share a link they can annotate on the live app — not a screenshot, not an email thread
Once your own pass is clean, the client's review works best when they can point at what they mean. A staging URL sent over email produces feedback like 'the header area feels a bit off' — you spend the next exchange locating which element before you can fix it. Proxy-based annotation tools (Drafty, Markup.io, Pastel) wrap your staging or production URL in a comment layer: the client opens the link in any browser, clicks the exact button or field they mean, and pins a note right there. 'The CTA on the pricing page is hard to spot' lands on the CTA, not in a three-line email. The thing that kills this workflow: a review tool that requires the client to create an account. A busy client who hits a signup prompt before they can leave a comment will close the tab and send you an email instead. Use a tool where guest commenting requires zero setup — they open the link and click.
Paste your staging URL into Drafty and share the review link. Your client opens it on any browser, clicks the exact element they mean, and pins a note — no account, no install. Every comment threads in one place, anchored to the spot. When you push a fix, the updated app lives on the same link. No new URLs, no re-exports, no iMessages describing 'the button near the top.'
Open a live demoQuestions
- What should I check when reviewing a web app before showing a client?
- Four areas catch the most client feedback: edge-case states (empty states, error messages, loading states on a slow connection), the primary flow from a first-time-user perspective with no prior context, copy at mobile width (button labels that truncate or error messages that expose raw codes), and the app on a real phone — not just a desktop browser. Most review misses happen in states that only appear when something is empty or broken.
- How do I share a web app with a client for review without giving them edit access?
- Use a proxy-based annotation tool: paste your staging or production URL, get a review link, share that link. The client can see and annotate the app but can't touch the underlying code or content — they only leave comments on their copy of the review layer. This is different from sharing a CMS login or a Vercel project invite, which would grant actual access.
- How do I get specific feedback on a web app instead of 'it feels off'?
- Change the channel: give the client a review link where they click the exact element and pin a note to it. Vague feedback comes from reviewers who can only describe, not point. When the description replaces pointing, 'the bit near the top' is the best they can do. A note pinned to the actual nav item produces 'this label isn't clear' instead. Also helps: two or three specific questions in the message alongside the link ('Does the onboarding feel like it's asking for too much upfront?').
- Can a client annotate a staging URL without creating an account?
- Yes, with tools that support guest commenting — Drafty, Markup.io, and Pastel all allow it. If your staging environment is behind HTTP basic auth, the annotation tool will hit that prompt before rendering. In that case, either temporarily remove staging auth for the review window or whitelist the tool's rendering IP. Alternatively, export the key pages as screenshots and share those as an annotated image canvas for the review.
- What is the difference between reviewing a web app and reviewing a website?
- The main difference is interaction depth. A website review focuses on layout, copy, and navigation — mostly stateless pages. A web app review has to cover state: what happens when data is missing, when a form errors, when a session expires, when the user is mid-flow on mobile and their connection drops. Web app reviews should include authenticated and unauthenticated states, because clients will notice the logged-out view even if they only see it once.
- How many revision rounds should a web app review take?
- One structured round is the target. Two is typical when the designer skips their own pass and the client finds the preventable issues. Three or more usually means the client is annotating on email or screenshots — so each round starts with an exchange to decode what they meant before any fix happens. Running your own edge-case and copy pass before sharing, then using an annotation tool for the client's round, compresses most reviews to one meaningful pass and one small tidy-up.
Keep exploring
Stop emailing files back and forth.
Share one link. They comment on the exact spot — no account, always the current version.