You send a reviewer a link, they open it, and the first thing they see is a signup form or a request to install a browser extension. That is where the feedback stops. Your client, your compliance officer, your VP who agreed to look at the staging build, none of them will create an account to leave three comments. They close the tab and reply to your email with two vague sentences instead.
This is not laziness. It is a rational response to a bad trade. You are asking someone to spend five minutes and their trust on a tool they will use once, so they can do you a favor. The math never works out in your direction.
Why the install prompt kills feedback
Every account, extension, or download is a decision the reviewer has to make on your behalf. On a corporate machine, a browser extension often cannot be installed at all without IT approval, and getting that approval takes days you do not have. A desktop app triggers the same wall. Even a free signup form asks the reviewer to hand over an email, pick a password, verify it, and accept terms they did not read.
Each of those steps loses people. The reviewer who was mildly willing to help becomes unwilling the moment there is friction. And the friction compounds: the more external the reviewer (a client, a contractor, a legal reviewer), the less patience they have for your process. The people whose feedback you most need are the ones least likely to jump the setup hurdle.
The usual workaround makes it worse. You give up on the tool and ask for feedback over email or a call, which produces exactly the vague, unactionable comments you were trying to avoid. "The header feels off" is not something anyone can fix. You wanted specific, pointed feedback, and the setup barrier is the reason you did not get it.
Remove the account, and the feedback comes back
The fix is to move the friction off the reviewer entirely. If the reviewer can open a browser tab, capture what they see, talk or type through it, and send you something concrete without installing anything or creating an account, the setup wall disappears. That is the whole idea behind a no-install alternative to Markup.io: the reviewer does the work in a browser tab and never hits a signup screen.
With Cobalt Capture, the reviewer clicks Capture screen, the browser prompts them to share a window, and the current frame is drawn to a canvas. They crop to the part that matters, drop a numbered pin on the exact spot, and add a comment by typing or by dictating out loud. No extension. No download. No password. When they publish, the review gets a short public URL anyone can open.
Compare that to the tools built around review rounds and seats. Many of them, including several covered in the BugHerd vs a no-login review link comparison, assume every participant has an account. That assumption is exactly what breaks the workflow for one-off external reviewers.
What the reviewer actually does, step by step
The reviewer's side stays short on purpose. If you send a client the link to a build, they can run the whole pass in a few minutes:
- Open the link you sent, or go straight to start a new review.
- Click Capture screen and share the tab or window they want to comment on.
- Crop the still to the relevant area, or keep the full frame.
- Add a comment by typing, or by dictating with the browser's built-in speech recognition.
- Drop a numbered pin on the button or field they mean.
- Publish, and copy the resulting link back to you.
Nothing there requires a decision about installing software. Dictation works in Chrome and Edge; if your reviewer is on Firefox, they type instead, which is covered in the note on what to do when your reviewer is on Firefox. Everything else is identical across browsers.
What you get back, and why it is actually usable
The output is the reason this is worth doing, not just an easier way to send comments. Each published review is a public link, a PDF, and a Word document, so a person can read it however they prefer. The same review is also available as clean markdown, which is the format an AI coding agent reads directly. You capture once and hand the same feedback to a client and a developer, an approach spelled out in the client-and-developer link workflow.
Because each comment is attached to a cropped screenshot with a pin, the feedback is specific by construction. The reviewer cannot leave "the header feels off" floating in an email. They point at the header, crop it, and say what is wrong. That is the difference between a comment you can act on and one you have to chase down. For a walkthrough of running this on a live build, the staging site review before it ships post shows the full pass.
Anyone with the link can also comment on individual items, and you as the owner can mark each one resolved as you work through them. No bug tracker, no assignees, no workflow states. Just the review, the comments, and a way to close them out.
The next time a stakeholder agrees to look at something, do not send them a tool that asks them to sign up. Send a link they can open cold, and get feedback that someone can actually fix.