ruttl lets you edit the page you are reviewing.
Snag opens the pull request that fixes it.

ruttl is a website review tool and an unusually literal one: comments are pinned to the pixel on a live page, and text, alignment and imagery can be changed in the browser while you look at them. Snag works at the other end of that. Nothing on the live page is touched: what gets recorded is what the browser did, the DOM played back, with the console and the failed requests beside it, filed as a ticket in Jira or GitHub. Personal data is masked in the browser before anything uploads — inputs are never recorded. The change itself turns up in the repository, as a pull request carrying a repro test that fails before the fix and passes after.

Where they are genuinely good

Editing the live page is where ruttl is genuinely ahead of Snag: content, alignment and imagery all change in the browser, where a Snag fix run only ever produces a diff for a person to review. The ruttl mobile SDK reports bugs from inside your own app and carries the OS and app version along with them, where Snag records browser sessions only. The ruttl integration list runs to Jira, Slack, Trello, ClickUp, Zapier, Asana and Unsplash, where Snag connects Jira and GitHub. If the feedback you gather is about copy and layout rather than about code, ruttl is doing a job Snag does not attempt.

Where Snag is different

A change made inside a browser still has to be written into the source by somebody before anyone else sees it. Snag starts at the source. The capture that filled the ticket is what the coding agent reads: it reproduces the failure in a disposable copy of your repo, adds a test that fails on today's code and passes once the change is in, and puts the lot up as a pull request for review. Nothing merges without a human, and the sandbox is destroyed when the run ends. A run that gets to no pull request is charged at half, so an attempt costs less than a result, deliberately, and the first 5 fixes on every plan are free.

Which one to pick

Choose ruttl when the feedback is about copy, layout and imagery on a page a client is looking at, and being able to change it in place is worth more than what happens in the repository. Choose Snag when the report is a defect rather than a revision, when the person picking it up is going to be reading a stack trace rather than a comment, and when the bill should not move because two more people joined.

Snag and ruttl, side by side

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

Questions people actually ask

Is Snag a drop-in replacement for ruttl?

Not really, because they are aimed at different halves of the work. In ruttl the subject is a live page: comments land on the pixel, and content, alignment and images can be changed in the browser while you look at them. Snag never touches the page you are looking at. It records what the browser did — the DOM, the console, the requests that failed — and files that as a ticket in Jira or GitHub. Personal data is masked in the browser before anything uploads — inputs are never recorded. Whatever it proposes arrives in the repository instead, as a pull request somebody has to accept. If the feedback you gather is about copy and layout, these two are not substitutes.

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

This is a difference in kind, not in size. The ruttl Pro plan is priced per user: it costs $18 a month per user on the monthly toggle and $15 a month per user on the yearly one, so the invoice follows headcount. Snag has no per-user line at all: the workspace is the unit, and adding a designer, a QA lead or a contractor for a fortnight moves nothing. What the plan meters instead is fix-runs, sold as a monthly allowance. Today's numbers sit in the pricing section of the homepage.

ruttl puts MCP on its Pro plan. Where does Snag put it?

The tier and the job. The ruttl FAQ puts MCP connections and token generation on its Pro plan, and their MCP page describes the loop that enables: your own coding agent picks up a ticket and fixes it in your code. On the Snag side the server arrives with the Capture plan and only ever reads: it hands over the capture and writes nothing back, because the writing is what the fix run does and the fix run is part of what you bought. Both routes are supported here. Point your own agent at the server, or let the built-in run take it.

What happens when a fix run cannot produce a pull request?

It is charged at half, and you keep whatever evidence it gathered on the way. A run that does get there gives you three things: the diff, a repro test that fails on the code as it stands and passes once the change is in, and the capture the agent reasoned from. All of it happens inside a disposable copy of your repo, destroyed when the run ends, and the result then waits for somebody to read it — Nothing merges without a human. The first 5 fixes on any plan are free, so the first few cost nothing either way.

Where these details come from

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