You know the message. It arrives on a Friday afternoon.
"Hey, the site is broken."
So you write back. Which page? What were you doing? What browser? Can you send a screenshot? Was there an error in the console — actually, never mind, let me explain how to open the console.
Four messages later you learn it was Safari on an iPad, on a page you have never tested at that width, and the "error" was a 502 that resolved itself twenty minutes ago. The information you needed existed. It existed in their browser, at the moment it broke, and then it was gone.
The gap
There is a permanent asymmetry in bug reporting. The person who experiences the bug has all the evidence and cannot recognize any of it. The person who can fix the bug recognizes all of it and has none.
Every bug reporting tool is an attempt to bridge that gap. Most bridge it by asking the user to carry the evidence across, which fails, because the user does not know what evidence is.
Asking a user to describe a bug is asking them to do the hardest part of debugging — deciding what is relevant — with none of the context that makes it possible. They tell you the button doesn't work. They don't tell you the request returned 500, because they never saw it.
The other direction
So don't ask.
The evidence is already in the browser. The console has the error. The network log has the failing request. The DOM has the layout at the width where it broke. The user is standing in the middle of a complete crime scene, unable to see any of it.
BugDump's premise is that the user's only job should be clicking a button and saying, in their own words, what went wrong. Everything else gets collected without asking:
Console logs, including from before the widget was opened
Network requests, with status and timing
A session replay of the DOM
Their clicks, inputs, and navigation, in order
Browser, OS, viewport, page URL
A screenshot they can annotate — and blur, before it ever leaves their machine
The user writes "the button doesn't work." You receive that sentence attached to a 500 response, a stack trace, and a replay of the twelve seconds before they gave up.
What changes
The obvious win is speed. Reports that took four round-trips to become actionable arrive actionable.
The subtler win is volume. Most bugs are never reported at all. Not because users are indifferent, but because reporting is expensive — filling in a form, explaining the context, answering follow-ups, and probably never hearing back. Users perform a quick calculation and decide it isn't worth it. They just stop using the broken feature.
When reporting costs one click, that calculation changes. You hear about the bugs that were never worth mentioning, which are frequently the bugs quietly costing you users.
Closing the loop matters too. A report submitted into a void teaches people not to report. So BugDump gives each project a public portal where reporters can watch their task move from Confirmed to Done. Someone who sees their report get fixed files the next one.
The part we didn't expect
We built the capture layer first, because that was the obvious problem. Then something else became obvious.
Once a report contains complete, structured telemetry, it is no longer just documentation for a human. It is a well-formed input for an AI agent.
So we shipped an MCP server. Claude Code connects to BugDump and reads tasks, reports, and full telemetry directly. The workflow becomes:
Look at task #42 in BugDump and fix it.
The agent pulls the console error, finds the failing request, locates the matching code, and proposes a fix. You never open the dashboard.
That is only possible because the report is complete. An agent cannot ask a user which browser they were using. It gets one shot at the evidence, which means the evidence has to be there in full — the same property that makes a report good for a human makes it usable by a machine.
Where we are
BugDump v1.0 is live. One script tag, a triage board, eight integrations, webhooks, and the MCP server. The free tier is a real tier — 500 reports per project, forever, no card.
We are building this in the open. The changelog is public, the roadmap is public, and the feedback board is open. If the tool is missing something your workflow needs, tell us — preferably through the widget, so we get the console log too.