You run a small agency. A client emails: "the pricing page looks broken on my laptop, and the hero copy needs another pass." You have two reasonable ways to get that feedback into a state your team can act on. You can stand the client up inside BugHerd, where every comment becomes a ticket pinned to the live page. Or you can send them a link that opens a browser tab, lets them capture the screen, talk through it, and ship back something readable in two minutes.
Both work. They suit different jobs. Here is where each one earns its keep.
What BugHerd is actually selling agencies
BugHerd's pitch is a bug tracker bolted onto your client's website. Reviewers install a browser extension (or you embed a JavaScript snippet on the site), and from then on every comment is pinned to a live element, tagged with browser and OS metadata, and dropped into a kanban board with statuses, assignees, and a backlog. It is project management with a visual front door.
If you are running a long engagement with the same client across many pages, that structure pays off. You get a single board per site, a trail of who said what when, and a place to triage the inevitable backlog of "small tweaks." QA leads who think in tickets like it. Project managers who bill against tasks like it more.
The cost of that structure is real. Someone has to set up the project, get the snippet on staging, walk the client through the extension, and keep the board groomed. Pricing is per project and per user, and the lowest tiers cap how many active sites you can have at once. For an agency with five live clients, that is a fixed monthly line item plus a recurring setup tax every time a new project starts.
What a no-login review link is selling instead
The opposite shape is a single shareable URL. The reviewer opens a tab, clicks capture, picks a window, crops if they want, and either types or dictates a comment. They hit publish and send the link. No install, no extension, no signup. That is the model behind using Cobalt Capture instead of BugHerd for work that does not need a board behind it.
The trade is honest. There is no kanban, no assignee field, no "in progress" column, no per-site project that persists across months. Each review is its own artifact: a public link at /r/<slug>, a PDF or Word export for clients who want a document, and clean markdown at /r/<slug>/markdown for anyone (or any agent) reading it downstream. People with the link can comment on individual items, and the owner can mark each comment resolved. That is the whole workflow.
It is free. An account is optional. An anonymous review sticks around for 30 days and can be claimed later by signing in.
The dimensions that actually decide it
| Dimension | BugHerd | No-login review link |
|---|---|---|
| Setup for the client | Install extension or load snippet, learn the pinning UI | Open a URL, click capture, talk or type |
| Setup for you | Create project, add site, invite users, configure board | None per review |
| Persistent backlog | Yes, kanban with statuses and assignees | No, each review stands alone |
| Pins on specific spots | Yes, pinned to live DOM elements | Yes, numbered pins on the captured still |
| Annotation | Draw and label on the live page | Crop the still; comment in text or voice |
| Output for a developer or agent | Ticket in the BugHerd board | Public link, PDF, Word, or markdown |
| Cost | Per-project, per-user subscription | Free |
| Account required | Yes, for everyone on the board | No, optional and free |
Where BugHerd earns its price
Pick BugHerd when the work has the shape of a project, not an errand. A six-month redesign with weekly client review cycles. A maintenance retainer where the same client logs five small issues a week and you need a backlog you can groom. A team large enough that "who owns this ticket" is a real question. A QA lead who wants browser and OS metadata captured automatically on every report. If you are billing against a ticket count, the board itself is the deliverable.
Where the overhead gets in the way
Pick a single review link when the work is bounded. One round of client feedback on a draft homepage. A staging site walkthrough before launch. A design review with a freelancer who is never going to log into your agency tools. An accessibility pass you want to hand to a contractor as a document. Anything where asking the client to install an extension or sign up for an account will cost you a day of back-and-forth that the feedback itself would not.
It is also the right shape when the receiver is an AI coding agent. The markdown export at /r/<slug>/markdown is built so a tool like Cursor or Claude Code can read it directly. If most of your bug reports get handed to an AI coding agent for the actual fix, a kanban board is not what you need; a clean text artifact is.
A practical way to decide
Ask two questions about the next client. Will the same person file ten or more pieces of feedback against this site over the next month? And do you need a board to triage them? If both answers are yes, BugHerd's structure is worth paying for. If either is no, you are paying for overhead you will not use.
You can run both. Use BugHerd on the two clients where the backlog is real. For everything else, send a link from a fresh review and skip the project setup entirely. The full comparison hub covers how this shakes out against Jam.dev, Markup.io, and Pastel if those are also on your shortlist.