Userback sorts the feedback and routes it.
Snag turns the bug into a pull request.

Userback is a feedback tool. A widget sits in your app, arrows and shapes go on the screenshot, an AI layer sorts what arrives into bugs, ideas or feedback and writes the titles, and an MCP server lets a coding agent write back through it. Snag collects one kind of thing and takes it further. A click records the session replay, the console and the network — on every plan, with no developer tier to reach first — masks personal data in the browser, and files the report into Jira or GitHub. A sandboxed fix run reads that same recording and comes back with a pull request and a test that fails before the change and passes after it.

Where they are genuinely good

Userback is ahead of Snag in four places. The Userback MCP server writes as well as reads, so a coding agent can create an item, comment on it, change the status, the priority and the owner of that item, and move it through the workflow, where the Snag server hands out evidence and nothing else. The Userback markup tools draw arrows, circles and shapes onto the screenshot. Userback publishes a figure of 12+ project tools, where Snag connects Jira and GitHub. And the Userback mobile SDK is native iOS and Android on their Business Plus tier, where Snag records browser sessions only.

Where Snag is different

A well-sorted queue is worth having, and it is still a queue: nothing on it moves until something in the repository changes. That step is what Snag is for, which is why the evidence cannot sit behind a tier. Replay, console and network are recorded on every plan here, free one included and masked in the browser before anything uploads — inputs are never recorded. An agent that cannot see the request that failed has nothing to work with. What it makes out of that is a pull request, with the failing-then-passing test attached and a person deciding whether it merges. Nothing merges without a human, and the sandbox it worked inside is destroyed when the run ends. Runs that end with no pull request are billed at half, and the first 5 fixes on every plan are free.

Which one to pick

Choose Userback when what you collect is wider than bugs and the job is sorting and managing it at scale. Choose Snag when the queue is already bugs, when the console has to be in the ticket on whatever plan you are paying for today, and when the outcome you are after is a shorter list rather than a better-organised one.

Snag and Userback, side by side

Every Userback cell links to the page we read it on.

Questions people actually ask

Is Snag a drop-in replacement for Userback?

It depends what you collect. The Userback product collects feedback: a widget in your app, markup tools on the screenshot, and an AI layer that sorts what arrives into bugs, ideas or feedback, detects sentiment and writes the titles. Snag is narrower on purpose and does not pretend otherwise: it takes bugs. One Snag capture carries the replay, the console and the network into Jira or GitHub, on whichever plan you happen to be on, and a fix run answers it with a pull request. If half of what you gather is feature requests and sentiment, these two are not substitutes.

How does Snag's pricing compare to Userback's?

Every headline figure Userback publishes is the annual rate. The Team plan costs $29 a month when billed annually and $39 a month when billed monthly, and it carries five seats; Business costs $79 a month billed annually and Business Plus $159 a month billed annually. The tier matters more than the figure, because console logs, network requests and custom data arrive with the developer tools on the Business plan. Snag has one workspace fee with no seat count inside it and no tier at which the developer evidence switches on — the replay, the console and the network are recorded on the free plan too. What a plan sizes here is fix-runs. Current numbers are in the pricing section of the homepage.

The Userback MCP server writes as well as reads. Does the Snag one?

No, and the asymmetry is deliberate. The Userback server reads and writes: a coding agent can create feedback items, post comments, change status, priority and ownership, and move an item through the workflow. The Snag server reads. It answers with the capture behind a ticket, and the one thing it writes is the link to a pull request your agent opened — there is no verb for status, priority or ownership, which is a smaller surface to reason about and a smaller one to audit. The writing is what the fix run does, and what it writes is a pull request you review rather than a queue you manage. Either way of working is fine here — your own agent on the server, or the built-in run.

What does a Snag fix run produce, and who approves it?

A pull request, and you are the one who approves it. The run reproduces the bug in a disposable copy of your repo, destroyed when the run ends, writes a repro test that fails before the change and passes after it, and attaches the capture it worked from so a reviewer can audit the reasoning rather than accept it. Then it stops: Nothing merges without a human, on every plan. Runs that end without a pull request are billed at half, and the first 5 fixes on any plan are free.

Where these details come from

Every Userback detail on this page links to the Userback page we read it on, with the date we read it. Something out of date? Email admin@dvcllc.io and we will fix it.