Comment threads normally require identity, and for good reason — a note has to belong to someone. Here's how a review works when the reviewer signs into nothing, what that costs, and when the trade is the right one.
The reason external review is hard has almost nothing to do with review. It's that most tools ask the reviewer to become a user first.
That request is reasonable everywhere it comes from. A comment is a claim by a person; a thread needs a stable author; replies and notifications need somewhere to go. Identity is load-bearing, and an account is the standard way to carry it.
It also lands very differently depending on who's receiving it. For a colleague, signing in is nothing — they already have the account. For a client, it's a request to create credentials for a product they didn't choose, won't use again, and are being asked to adopt in order to do you a favour.
When you evaluate a review tool, you're testing it as the owner. You make an account because you were always going to, you learn the interface because it's your workflow, and the setup cost lands on someone who is motivated.
The reviewer's experience runs on entirely different economics. They're doing you a favour, on a deadline that isn't theirs, from a device you didn't anticipate. Every step you add is a step they can decline without consequence — and unlike you, they have no reason to push through friction.
This is why "we sent it, they never got back to us" is so often a tooling outcome rather than a relationship one. The note that never arrives leaves no trace. There is no log entry for a client who opened a signup screen, decided to deal with it later, and didn't.
If a comment still needs an author, and the reviewer isn't creating an account, the requirement has to sit somewhere. It sits in the link.
An address with enough randomness in it can't be found by guessing or crawling. That makes holding it meaningful — the same logic as a password reset link or a private calendar URL. The link is a bearer credential: whoever has it was given it.
Once access is settled by the link, attribution can be much lighter. The reviewer types a name alongside the comment, and the thread reads as a conversation — you can tell who said what, follow a disagreement, and tell two rounds of feedback apart. What you don't have is proof they are who they say. In a four-person review where you personally sent all four links, that proof was never doing much work anyway.
Share the private link you already sent and switch Review on. Whoever opens it clicks the spot they mean, leaves a name, and types.
The link-as-credential model has a real boundary, and pretending otherwise would make it less useful.
A typed name is a claim, not proof. Use it where misattribution is a nuisance rather than a problem: design feedback, copy review, a client reacting to a prototype, a colleague marking up a draft.
A bearer link survives forwarding. That's usually a feature — your client loops in their colleague and it just works, no invitation dance. It's a liability when the contents are sensitive, and the answer there is to pair the link with a password or an expiry so access can be closed rather than merely unadvertised.
Some reviews need accounts and should have them. Formal approvals, compliance records, per-person permissions, provably closed reviewer sets. If a comment might one day be evidence, verified identity is the correct instrument, and the friction is the point.
The error isn't picking either model. It's applying the heavy one to a light job — putting a signup wall between a designer and a client's reaction to a prototype, and then wondering why the prototype sat unopened.
Can they open it without installing anything? Extensions and joined sessions are where external reviews stall. If the whole of their setup is "click the link", you've removed the main failure point.
Does the note land on the thing it's about? A comment pinned to an element carries its own context; a paragraph in a chat window makes you reconstruct which element from memory. That difference compounds when the notes are going back into an AI prompt rather than into your own head — which is the whole reason exporting a pinned thread back to your AI works better than paraphrasing it.
Does the link survive the next revision? Reviews run in rounds. If revising means a new URL, every round starts with a message explaining the old one is dead. If the address holds, the thread stays attached to the work — the loop the page was made for, rather than hosting, which was never the job.
Nobody skips leaving feedback because they don't have opinions. They skip it because between the opinion and the box to type it in, there was a form.
Skip the review call. Send the prototype as a private link, let people pin comments to the exact element with no account, and read every note in one place — async, on their schedule and yours.
Client-side encryption tools turn your page into an encrypted file, so the protection and the artifact are the same object — every edit means re-running the tool and re-uploading. What that actually costs, the salt setting that decides whether your old share links survive, and when a hosted password is the better trade.
Running the studio out of one folder per client is a good structure for making the work. It stops at the point where the client has to open it — a private repo needs a GitHub account, and Pages built from one is public by default. What the handover step actually needs, and how to add it without breaking the folder.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.