Show HN: Most users won't report bugs unless you make it stupidly easy
After shipping a few SaaS products, I noticed a pattern: Bugs? Yes. Bug reports? No.
Not because users didn’t care but because reporting bugs is usually a terrible experience.
Most tools want users to:
* Fill out a long form
* Enter their email
* Describe a bug they barely understand
* Maybe sign in or create an account
* Then maybe submit it
Let’s be real: no one’s doing that. Especially not someone just trying to use your product.
So I built Bugdrop.app - It’s a little draggable bug icon that users can drop right on the issue, type a quick note, and they’re done. No logins. No forms. Just context-rich feedback that your team can actually use — with screenshots, browser info, even console logs if they hit an error.
And weirdly? People actually use it. Even non-technical users click it just because "the little bug looked fun."
I didn’t want to build another "feedback suite". I just wanted something lightweight, fast, and so stupidly simple that people actually report stuff. If you've ever had a user say “something’s broken” and then ghost you forever, you probably get where I’m coming from.
What I’m most proud of? People are actually using it. And their users? They’re actually reporting stuff. Even non-technical ones.
Would love to hear if you’ve faced similar problems, and if this feels like something that would’ve helped in your own projects. Not trying to sell you anything — just sharing something I built to scratch my own itch.
Now the linux-industrial complex is a special case, if you are a software engineer and know how to isolate a problem and submit a great bug report you will often hear from people who will say you sent them the best bug report all quarter. It helps if the team is working with web tech, younger, more diverse, and never heard of the GPL.
As a submitter, you can decide to invest in someone's detailed bug report form, including attaching screenshots, etc., maybe taking up to an hour, and derailing the work mental mode you were in.
After that work, what you learn most likely happens next is one of the following:
* Silence.
* "Yes, that's a problem." Then silence.
* 6 months later, automated email saying that this bug is automatically closed, due to inactivity.
* 2 years later, automated email that they've done a new release, so they've decided to throw away all open bug reports. But if you still find the bug in the new version, you can file a new bug report, they graciously offer.
* "We know about that bug, but we aren't going to fix it." For reasons you don't understand. And if there's a cultural mismatch, the tone can come across as hostile or disingenuous, besides.
* "This is a duplicate of bug X." It is not.
* Closes the bug report suspiciously, perhaps for optics or metrics.
* (Silence FAANG Special Edition: A high-profile bug report, on which tens or hundreds of knowledgeable people are adding on, for years, all saying this bug is a huge problem, and many asking in the bug report comments why is nobody from the FAANG even acknowledging this bug report in their own bug system.)
Suggested practice: If you ask others to invest in reporting bugs (by having that bug report form there), then follow through in good faith on the bug reports you receive. (At least on the bug reports that seemed reasonable, and that invested effort in your process.)
I agree that reporting bugs can be hard, but the amount of spam that follows an effective open form, of craziness to uselessness, outweighs the useful bug reports.
Having two types of reports: one which is a simple screenshot taker with the ability to draw a circle over what is wrong, and one which is a more detailed report, would be useful.
Some LLM that filters out what is a useless report be a useful report would be good, too.
That's entirely the wrong take, IMO.
Listening to users is easy, but the users often don't say anything when they speak. Those non-reports are basically spam that should be automatically thrown away.
In comparison to _paid_ software testing, which doesn't change the point at all: if they were paid to find bugs, they wouldn't be paid for useless and unactionable reports.
>you’re complaining that listening to your users is hard
Sometimes - and I'd wager most of the time - they are, yes, unless your product solely attracts technically competent and advanced users that can attempt to understand/reason about what is causing the issue.
I however wouldn't shorten/transform reports with an LLM, or make spammy reports inaccessible. Just doing the semantic grouping for escalation. It's true you're getting free work from your users, and the human factor is pretty important here, even if an LLM might sometimes misinterpret it.
This so much.
I can't tell you how often I've seen someone trying to get tech support on something say "When I load the program, I get an error" but don't even say what the error says. I understand that most people have never worked a QA job and so don't know how to write a good bug report, but certainly I would expect someone to copy/paste the error message.
Possibly disclosing sensitive information (which the user may not realize).
Maybe people could combine this reporting solution with a bug capture solution I built a few weeks ago? It's a web-based screen recorder which allows a user to gather together several different areas of the screen into one place, add a talking head of themselves and demonstrate/explain the problem they've encountered. The resulting video could be added to the bug report. I built the tool because showing the problem is always better than trying to explain it in words.
Tool: https://kaliedarik.github.io/sc-screen-recorder/ GitHub repo (it can be forked, self-hosted, etc): https://github.com/KaliedaRik/sc-screen-recorder
There are two bugs in Firefox I'd like to report, but it's futile. One is that, launched on Ubuntu, Firestorm does disk I/O for about three minutes on launch. During that period it can't load complex pages, although it loads ones without Javascript fine. The other, again on Ubuntu, is that it freezes when large text boxes are being filled in. This only happens on some sites.
I remember finding 3 year old reddit post about this, and I have no idea whether the bug got into normal reporting place (where even is it?)
I have found that users don't give feedback, positive or negative, until they encounter some extreme (usually negative).
I have found the best way to encourage feedback, is to make it dirt simple. Just a text entry field, with some way to respond, so you can follow up.
Most of the work needs to be on my end.
What other industry relies on its customers as implicit developers?
Making bug reporting easier means an intentional push to foist more of Development's work upon customers and a bias towards more bugs.
BUG OR FEATURE?
If you can't tell, then we can understand why Knuth call it "the art" of computer programming, as in the artist's uncertainty of creation as compared to the engineer's confidence.
The fact that half the SW industry prefers to avoid a distinction between bugs and features— as in bugs that don't get reported are regarded as features— shows the profligate laziness and opportunism of so called Software Engineering.
AI is a stunning example of a global industry built by computer technologists who don't care about understanding their own work, and lack the creative and social spark to conduct themselves as artists.
Just listen G. Hinton babble philosophically for 10 minutes and you will grasp the magnitude of incompetence at work.
The number of hardware and software combinations are impossibly large, so you're unlikely to be handling everything perfectly if the application is doing anything complicated.
Hooooever, "bug" could be a bit ambiguous to a lot of people. Looks like in a real deployment, you have a little tooltip that says "Spotted a bug? Drag me there!". That makes sense to developers and the like... but those are also the sorts of people most likely to write a good bug report anyway. The people most unlikely to write a bug report are the sorts of people who will read "spotted a bug" as "there is an insect... game?... on this site?".
"Issue" or "Problem" would be better, but keep the bug graphic! It's cute. :)
I also have no idea how well this works on mobile - and seeing that the Pro plan doesn't remove attribution seems like a mistake.
Only thing I would add is after submit it should allow you to enter an email address or something so that (a) the user can get updates on the progress of fixes; and (b) be contacted if the dev needs more info.
Here's some quick feedback -- hope it's useful:
1. Is the little bug icon sufficiently visible? I'm not sure...
2. Do visitors automatically know what to do with the bug? You have a tooltip, but do all visitors know what "Spotted a bug?" means?
3. [more of a suggestion; perhaps it does this already] Would be great if the bug position pulled in a CSS class or the content surrounding the "dropped" bug -- to give more context to the site owner.
The other method I used is to have audit logs, identify when there are errors in certain steps.
It's the reason apple became apple, even though I don't think the iPhone is intuitive today.
It doesn't have to be difficult. It just has to be not easy.
1. I load https://bugdrop.app/
2. The site days 'try bugdrop' and points to the left bottom corner.
3. I click the bug. Nothing happens.
On further inspection, there is sometimes a tooltip that tells me clicking won't work and I need to drag the bug over the part of the UI that failed, but I didn't read that when I first used it and I won't use it a second time.
I've worked with people who uttered this phrase many times. You really should put this on your CV because it's an incredibly helpful indicator of character trait.
It is an approach, for sure.
A) only pay for perfection and
B) experience zero friction or cost in moving services?
See, if you rely on a vendor, then you need them to survive. It’s a parasite-host relationship. You need to tell them what you need, and oftentimes they will bend the roadmap in favour of the most demanded features. Alternatives:
- They choose their most amusing feature,
- They choose the most lucrative feature among the new possible markets while ignoring all bugs, which is the most rational way to address bugs unfortunately,
- You don’t tell them, they don’t improve, they die / they triple the price of the product by lack of audience, and you have to migrate your data to another product.
FAQ says "The Bugdrop snippet is tiny and loads asynchronously"
So, you add a snippet of JS to your site.
What happens after the user files a bug from their point of view? Is there a follow-up, or is it like throwing a message in a bottle?
On macOS .app is the standard extension for any installed app.
Every bug I encounter in my favorite game I do not report because they want:
* My email, yet again.
* A long form
* A bug description rather than a narrative of what I experienced
The only exception is indie apps I pay for on the App Store. There is usually only one or perhaps two people behind it, so by definition that person is SWE, QTE, PM and several jobs rolled into one. And this is unsustainable unless the app is paid.
No comments yet
No comments yet