Reviewa

The Spark

Every time I wanted feedback on something on the web, the ritual was the same and slightly broken. Take a screenshot, paste it into a doc, draw an arrow, and hope the person could map my arrow back to the real thing. Or send a link with a paragraph of “the button in the top right, no the other one.” The feedback always drifted away from the thing it was about.

The web already solved this for documents. Google Docs comments sit right next to the words they refer to, and everyone can see the same thread. I wanted that same feeling, but for any web page, and for the half-built prototypes I spend most of my time looking at. Paste a link, get a page people can mark up in context, no account required. That was the whole itch.

One Idea, Two Problems

The concept is simple: comment on anything, in place, without making anyone sign up. But “anything” splits into two very different technical problems, and that split is why Reviewa is two products instead of one.

The first problem is a page you do not control. A live marketing site, a competitor’s landing page, something already shipped. You cannot add code to it, so the only way to make it commentable is to take a faithful snapshot and let people annotate the snapshot. That is Reviewa.Site.

The second problem is a page you just built. A prototype, a Claude or Figma Make export, a static build sitting in a folder. Here there is no live URL to freeze yet, so the job is to host the thing first, then layer comments on the running version. That is Reviewa.Work.

I kept them as two fully separate products on purpose: separate code, separate deploys, separate infrastructure. It means a change to the prototype-hosting side can never break the freeze-a-live-URL side, and vice versa. They share the idea, not the plumbing.

How It Works

Different capture mechanics, but the loop a person experiences is the same on both sides. The design goal was to make the share link the reward for setting things up, not the first thing thrown at you.

The owner keeps a private link that acts as the key. Reviewers get a clean share link and nothing they should not see.

Some Learnings

Building the same idea two ways surfaced a few things I did not expect, and a couple that only become obvious once real pages start flowing through.

The hardest part of freezing a live page is not the screenshot, it is knowing when the page is actually done loading. Marketing sites are stuffed with trackers and chat widgets that keep the network busy essentially forever, so the naive “wait until the network goes quiet” approach never finishes and the capture times out. Waiting for the page’s load event instead, then settling briefly, turned out to be the reliable signal on exactly the tracker-heavy sites people most want to review.

Anchoring a comment to a moving target is a genuinely hard problem, and it is harder for prototypes than for frozen pages. A snapshot holds still, so a pin stays put. A live app can re-order or rebuild its own layout, which can make a pin latch onto the wrong element. I treat this as a real limit rather than a bug to paper over: the frozen side is inherently more stable, and the prototype side is best-effort but honest about it.

The most interesting lesson was about trust, not code. My first instinct on the prototype side was a slick one-line “run this command and your prototype is live” flow. The AI coding agents I tested it with correctly refused to fetch a URL and then run whatever script it told them to, because that is exactly the shape of a supply-chain attack. They were right to refuse. So I redesigned around honest paths: a plain web upload for most people, and an explicit command you choose to run yourself when you want it. Good security instincts in the tools were a feature to design with, not around.

And a smaller one that mattered to me: I kept analytics off the actual review and comment pages entirely. It only runs on the public marketing pages. If the whole pitch is that reviewers do not need an account and are not being tracked, that promise has to be real on the exact pages where they are doing the commenting.

Fun to Build, Easy to Extend

This is one of those projects that is genuinely fun to build, mostly because the core loop delivers value almost immediately. Someone pastes a link, shares it, and a minute later real feedback is landing in context. There is no onboarding to sit through and nothing to install. That fast payoff is also what makes it so easy to keep going, because once the loop works you can start stacking features on top of it, and each one is a small, self-contained win rather than a rewrite.

A few directions I keep sketching:

• Password-protected links. A simple gate on a review so a client link is not wide open to anyone who gets the URL. Optional per project, off by default to keep the no-friction feel.
• Custom domains. Let a team serve reviews from feedback.theircompany.com so the whole thing feels like their own tool. The prototype-hosting side already runs on wildcard subdomains, so this is a natural next step.
• GitHub PR integration. Point Reviewa at a pull request’s preview deploy, and push the pinned comments back as PR review comments. Design feedback and code review stop living in two different places, and a designer can comment without ever opening GitHub.
• Agentic reviewers. This is the one I am most excited about. Turn an AI agent loose on a captured page or prototype and let it leave comments alongside the humans: flagging accessibility issues, weak or off-brand copy, broken links, confusing flows, inconsistent spacing. It shows up as just another reviewer in the thread, so a human can reply, agree, or wave it off. You could even run a few specialized agents at once, one for accessibility, one for copy, one for visual polish, and let them argue in the margins before a person ever looks.
• Feedback that resolves. Comment status (open, resolved, will not fix), assignees, and a running count of what is left, so a review has an actual finish line instead of an endless scroll.
• Version compare. Re-capture the same URL over time and diff it, so you can see what changed between rounds and whether a comment was actually addressed.
• Smart round-up. An AI pass that reads every comment on a review and clusters it into themes, so instead of forty scattered pins you get “eight people tripped on the pricing page” as a headline. Export those straight into Linear, Jira, or Notion as tickets.
• Richer comments. Voice notes, short screen recordings, and reactions, since sometimes pointing and talking is faster than typing a paragraph about the button in the top right.

None of these change the core promise. They just stack on top of a loop that already works, which is exactly why the project stays fun.

Where It’s Going

Both products work today, but “Active” is the honest status because the interesting work is still ahead, and most of it is on the prototype side.

The prototype hosting needs a proper owner view, so there is a real distinction between the person who set up the review and everyone leaving comments, with owner-only export. It needs expiry that actually runs, since the promise that links expire has to be enforced by a real cleanup job, not just stated in the footer. And the biggest gate before opening either product to arbitrary public use is security: hosting untrusted code and capturing arbitrary URLs both need real hardening, moderation, and abuse mitigation before I would put them in front of a wide audience.

The direction I am most curious about is a third door: a small snippet that adds Reviewa commenting to a prototype you already host somewhere else, no re-hosting at all. That would make the comment layer portable, which is really what the whole idea has been reaching toward.

Current Status

Both are live. Reviewa.Site freezes a live URL and lets a team comment on it with no sign-up. Reviewa.Work hosts a prototype and injects the same comment layer on top. Each links to the other, and links expire so nothing lingers forever.

Visit Reviewa.Site ↗ · Visit Reviewa.Work ↗