Igor
If you shipped an app from Lovable, Bolt, v0 or a similar builder, users will still find bugs, and they will send you screenshots in chat. Put a Report button on the app, let them point at what is wrong, and give those reports to the same kind of agent that wrote the code. The loop is: user reports, agent reads the evidence, you review the diff, agent resolves, user gets a "fixed" email. This is the longer walkthrough behind bug reporting for vibe-coded apps.
Why a screenshot in chat is not enough
You did not read every file the builder generated. The bug is often in a request you have never opened: a 422 from the auth endpoint, a 200 with an empty array, a client component that reads the wrong field. A screenshot of "it doesn't work" does not contain that. The user's browser did, for a few seconds.
You also cannot sit on a call with every first user. The report has to stand in for you being there: the page, the element, the error, the payload, the steps.
The loop
- Add the widget to the preview and to production. One script tag, or the npm package. It runs on localhost too, so you can try it yourself. See the install guides.
- The user clicks Report, points at the broken control and writes what they expected. They do not need a SnagRelay account.
- The report lands with the element, console errors with file and line, requests with request and response bodies, repro steps and a short replay. Secrets are stripped in the browser.
- You tell the agent in Cursor, Claude Code or Codex: fix
SHOP-18(or whatever key the report has). It callsget_issue_context, reads the failing request, edits the repo. - You review. Do not skip this. Generated apps plus unattended agents are how prompt injection in a public widget becomes a bad day; see prompt injection through bug reports.
- The agent calls
mark_issue_resolved. The user gets a "fixed" email. You do not have to remember to ping them in the same chat they used to complain.
Where the report should go
If the builder is the whole company, the SnagRelay inbox is enough: the agent reads it over MCP, you never open Jira. If you already file GitHub issues, connect GitHub and let the report land there too. One tracker per project: Jira Cloud, Linear, GitHub, GitLab.com, Trello or Azure DevOps Services. MCP is on the free plan.
What this does not do
- It does not watch every session. Only a report the user sends.
- It does not deploy the fix to Lovable or Bolt for you. The agent edits the code you have in git, or you paste the change back into the builder.
- It does not replace analytics. A funnel drop is not a bug report.
Start this afternoon
Install the snippet on the preview URL, file one report yourself, then in Cursor: fix that SnagRelay issue. If the agent can name the failing request without you pasting it, the loop works. Setup for each agent is on the MCP page. The first-person walkthrough with tool names is fix a client's bug from Cursor or Claude Code.
FAQ
How do I collect bug reports on a Lovable or Bolt app?
Add a reporting widget to the preview and production URLs. Users click Report on the page. Do not rely on Discord screenshots.
Can the same agent that built the app fix the bugs?
Yes, if it can read the report. Connect MCP, give it the issue key, review the diff, then resolve. It still cannot see what it was not given.
Do users need an account to report?
Not with SnagRelay's widget. They point and write what they expected.
What if the app is only on a preview URL?
That is enough. Put the widget there. Preview bugs are still bugs, and they are cheaper than production ones.