How do I get client feedback on a live web app without giving them edit access?

Share a review link generated by a proxy-based annotation tool. The client opens the link and comments on the exact element — they can't edit the underlying code or content, only leave notes. This is different from sharing a CMS login or a Figma editor link, which would grant edit access. Most annotation tools let you set the canvas to public-comment-only, so the client annotates and you receive the feedback on your end.

What is the best way to get feedback on a web app from a non-technical client?

A shared review link they open in a browser with no setup. Non-technical clients will not install a browser extension, create a developer account, or navigate a staging environment with HTTP auth prompts. A link that wraps the live app in an annotation layer — so they click what they mean and type their note — removes every barrier except writing the feedback itself. Specific prompts ('Does this button label make sense?') reduce the work further.

How do I collect feedback on a specific page of a web app?

Use the exact URL of that page — not the app's homepage — as the input to a review tool. The annotation link wraps that specific page, so comments land in context. If you need feedback on multiple pages, create a separate canvas for each one and share them in order with task prompts above each link. This prevents notes about the settings page and notes about the dashboard from piling into one thread.

Can clients annotate a staging URL without a login?

Yes, if the staging URL is public or if you use a proxy review tool that wraps it. If your staging environment is behind HTTP basic auth, the proxy tool will hit the auth prompt before it can render the page. In that case, either temporarily disable staging auth for the review period, whitelist the review tool's IP, or export specific screens from the browser and share those as an annotated image canvas instead.

How do I stop getting vague email feedback on my web app?

Two changes help most. First, replace the email with a review link they annotate directly — 'the top bit' becomes a pinned note on the exact nav item. Second, send a task prompt with the link: 'Walk through the onboarding and flag anything that's confusing or missing.' Open-ended requests get 'looks good' back; task-framed ones get notes on the specific gap. The combination cuts vague feedback by forcing location-specific input rather than general impressions.

Should I get feedback on a web app before or after development?

Both, but with different tools. Before development: share Figma designs or wireframes with an annotation link and collect sign-off on layout, copy, and flow — fast to change at this stage. After development: share the built staging URL and collect feedback on the real interactions, error states, and edge cases that wireframes can't show. Conflating the two phases costs the most time: redesigning a built page is expensive; fixing a note on a Figma frame is not.

drafty

How to get feedback on a web app

Quick answer

To get feedback on a web app, share a link your client opens in any browser and clicks directly on the element they want to flag — a button, a form field, a nav item — pinning a note right to it. The main failure mode is getting back an email that says 'the top bit feels off': you spend the next exchange locating what they meant instead of fixing it. Anchored notes on the live app cut out that round.

Step 1

Screen recording with a narrated walkthrough — fast, but one-directional

Record yourself walking through the web app on Loom, QuickTime (File → New Screen Recording), or OBS. Narrate what you want feedback on at each step: 'Here's the dashboard — I'm not sure the primary action is obvious enough. Now I'm clicking into the settings flow.' Share the Loom link and ask the client to leave time-stamped comments, or watch it on a call and take notes together. This is the lowest-overhead method and works well when you want to control what the client sees — useful for narrowing a broad review. The gap: a narrated recording shows your interpretation of the app, not the client's. If they have a different mental model — they expected the export button to be on the table view, not the detail page — a recording you steered won't surface that. You're also doing the clicking; they're not noticing what their own finger would catch.

Step 2

Send a staging or preview URL with written questions

Most web frameworks generate a unique preview URL per deploy — Vercel, Netlify, and Railway all do this automatically. Share the URL with two to four specific questions written below it: 'On the onboarding flow, does step 2 feel like a required field or optional?', 'Is the error message on the login screen clear about what went wrong?', 'Does the pricing page give you enough information to decide?' Specific questions get specific answers. 'What do you think of the app?' gets 'looks good, a few things to tweak' back — which costs you another round to unpack. The gap: a raw preview URL has no annotation layer. The client can see the app and form opinions, but feedback arrives over email or Slack, detached from the screen element it refers to. 'The nav item on the left' sent over iMessage might mean the sidebar link, the breadcrumb, or the tab — you find out which on the next exchange.

Step 3

Ask the client to annotate the live app directly

Proxy-based review tools — Drafty, Pastel, Markup.io — wrap your live web app URL in an annotation layer. Paste your staging or production URL into the tool and share the review link. The client opens it in any browser, clicks the exact button or field they mean, and leaves a note pinned right there. 'Guest checkout is buried' lands on the guest checkout button, not in an email three levels deep. 'I don't trust the payment form' lands on the payment step. No account, no extension, no install. This is the right method for design sign-off on a built web app: every note is actionable because it's location-specific. The practical caveat: form submissions and server-side interactions won't work through the proxy layer — the client can see and annotate the layout, but clicking 'Submit' won't actually post a form. Set that expectation in your message: 'This is for layout and copy feedback — the form won't submit.' If you need feedback on real interactive behavior (what happens when the user submits a bad input), a staging URL with a structured question list is more appropriate.

Step 4

Run a structured async walk-through for complex apps

For multi-page apps — a SaaS dashboard, an onboarding funnel, a multi-step settings flow — feedback gathered on a single URL can get tangled. The most reliable method is to share each section as a separate review canvas or page, with a short task framing above each one: 'Walk through the onboarding as a new user. Flag anything that's confusing.' Then: 'Now look at the dashboard after setup. Is the primary action clear?' A task prompt works because the client engages as a user, not a critic. Without it, a business-side client will leave copy feedback ('change the button text to…') and skip the UX gaps ('I couldn't find the export feature'). Loom timestamps and anchored comment threads can be combined here: watch the recording for context, then click through the review link and annotate the specific screens. Resolving notes inline — marking each thread 'fixed' or 'won't change' — keeps the sign-off round tight and prevents re-litigating closed feedback.

The faster way

If your client is the kind of person who replies to your preview URL with 'looks good, just a couple of things' and then sends you three separate iMessages describing the same button — paste your staging URL into Drafty and share the review link instead. They open it in their browser, click the exact element they mean, and pin a note right there. No account, no install. Every comment lands in one thread, anchored to the spot. When you push a fix, the updated version lives on the same link — no re-sending, no new URL.

Open a live demo

Questions

How do I get client feedback on a live web app without giving them edit access?: Share a review link generated by a proxy-based annotation tool. The client opens the link and comments on the exact element — they can't edit the underlying code or content, only leave notes. This is different from sharing a CMS login or a Figma editor link, which would grant edit access. Most annotation tools let you set the canvas to public-comment-only, so the client annotates and you receive the feedback on your end.
What is the best way to get feedback on a web app from a non-technical client?: A shared review link they open in a browser with no setup. Non-technical clients will not install a browser extension, create a developer account, or navigate a staging environment with HTTP auth prompts. A link that wraps the live app in an annotation layer — so they click what they mean and type their note — removes every barrier except writing the feedback itself. Specific prompts ('Does this button label make sense?') reduce the work further.
How do I collect feedback on a specific page of a web app?: Use the exact URL of that page — not the app's homepage — as the input to a review tool. The annotation link wraps that specific page, so comments land in context. If you need feedback on multiple pages, create a separate canvas for each one and share them in order with task prompts above each link. This prevents notes about the settings page and notes about the dashboard from piling into one thread.
Can clients annotate a staging URL without a login?: Yes, if the staging URL is public or if you use a proxy review tool that wraps it. If your staging environment is behind HTTP basic auth, the proxy tool will hit the auth prompt before it can render the page. In that case, either temporarily disable staging auth for the review period, whitelist the review tool's IP, or export specific screens from the browser and share those as an annotated image canvas instead.
How do I stop getting vague email feedback on my web app?: Two changes help most. First, replace the email with a review link they annotate directly — 'the top bit' becomes a pinned note on the exact nav item. Second, send a task prompt with the link: 'Walk through the onboarding and flag anything that's confusing or missing.' Open-ended requests get 'looks good' back; task-framed ones get notes on the specific gap. The combination cuts vague feedback by forcing location-specific input rather than general impressions.
Should I get feedback on a web app before or after development?: Both, but with different tools. Before development: share Figma designs or wireframes with an annotation link and collect sign-off on layout, copy, and flow — fast to change at this stage. After development: share the built staging URL and collect feedback on the real interactions, error states, and edge cases that wireframes can't show. Conflating the two phases costs the most time: redesigning a built page is expensive; fixing a note on a Figma frame is not.

Keep exploring

How to get feedback on a web design How to get feedback on a checkout flow Review a website Website feedback tool

Stop emailing files back and forth.

Share one link. They comment on the exact spot — no account, always the current version.

Open a live demo