You ship a new build on Tuesday, the client sends notes on Thursday, and half of them refer to the version you already replaced. That is the problem both approaches try to solve, and they solve it differently. Pastel gathers feedback into rounds attached to a page or design. The other model is to publish a fresh review link for each build and let comments and resolves live inside that snapshot. Which one fits depends on how your projects run and how much your clients are willing to learn.
What Pastel is built for
Pastel puts a comment layer on top of a live URL or a design file. A client opens the page, clicks anywhere, and leaves a pinned note. Everyone sees the same canvas, and the notes accumulate into review rounds you can reopen and track. It is a strong fit for a long-running relationship where the same page changes many times and you want the whole comment history in one place.
The cost is that the feedback sits on a live page. When the page changes, older comments can drift away from what they described. The client also lands in an interface they have to understand: which round is active, how to pin, where the thread lives. For a client who reviews one build every few weeks, that is overhead they resent.
What a per-build link does instead
The other model treats each version as its own artifact. You capture the screens that changed, add comments by typing or dictating, and publish. The review gets a short public URL, and anyone with the link reads it with no login and nothing to install. When the next build lands, you publish a new link. Build 3 and build 4 never bleed into each other because each is a fixed snapshot.
This is the model behind the Pastel alternative approach in Cobalt Capture. The reviewer captures a still, crops to the part that matters, and drops numbered pins on the exact spots. The image is frozen at the moment of capture, so a comment about the misaligned checkout button still points at that button a month later, even after the page is rebuilt.
People with the link can comment on any item, and you mark each comment resolved as you handle it. You get the review as a public link for people, a PDF or Word doc for a report, and clean markdown if a developer or coding agent is doing the fixes. One capture, several formats, no round to manage.
The dimensions that actually decide it
| Dimension | Pastel rounds | Per-build link |
|---|---|---|
| Client setup | Learns the commenting interface | Opens a link, reads, comments; no login |
| Feedback anchor | Attached to the live page | Frozen on a captured still |
| Version handling | Rounds on the same page | A separate snapshot per build |
| History in one place | Strong; all rounds together | Split across links you track yourself |
| Developer output | Comment threads | Public link, PDF, Word, markdown |
| Live annotation | Yes | No; crops a still instead |
The clearest split is the anchor. Pastel keeps notes on the living page, which is what you want when the page is stable and the point is to gather everyone's marks in context. A captured still is what you want when the build keeps changing and you need each comment locked to what the reviewer actually saw. There is a longer case for that in why a cropped still beats an annotated live page.
Where each one wins
Pastel wins when you run continuous review on the same asset and value having every round in a single tracked history. If your client is a regular collaborator who logs in without complaint, the accumulated context pays off.
The per-build link wins when the reviewer is a busy client you do not want to train, or when builds come fast and you need clean separation between versions. Because there is no signup, you can send a link to someone who reviews once and never returns. It also wins when a developer or agent is on the receiving end, since markdown bug reports come out of the same review without any extra step. This is the same reasoning that shows up in the BugHerd vs a no-login review link comparison for teams weighing a full tool against a link.
One more practical edge: you can point two audiences at one review. A client reads the public link while a developer opens the markdown, which is the setup covered in one review, two links for client and developer.
A quick way to test the fit
Take your next build and try both mentally. If your instinct is "I want all comments across every version in one dashboard I can reopen," Pastel rounds match that. If your instinct is "I want to hand this specific version to someone who should not have to sign up or learn anything," the link model fits. Most agency work that involves clients who review occasionally lands in the second bucket. The full breakdown of the frozen-snapshot workflow lives on the client feedback use case page.
The fastest way to know is to run one real review. Start a review of your current build, capture the two or three screens that changed, and send the link to the person who usually gives you notes. See whether they act on it faster than they did last round.