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.
218 comments
[ 725 ms ] story [ 5583 ms ] threadFAQ says "The Bugdrop snippet is tiny and loads asynchronously"
So, you add a snippet of JS to your site.
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.
2) I'm considering updating the popup text to something more approachable, like "Something’s not working?" or "Spot a problem?"
3) Currently, it doesn't send class names—but that's a great suggestion. Thank you!
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.
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.
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.
I’d always reply though, usually with something equally terse.
As a developer sharing my code online, I don't even know where to begin answering that.
This is typical non-tech spam.
If a user wants to use a piece of software to do A and several different pieces of code do that - why should they choose yours.
What is your selling point.
Especially if they have been using the other product why should they switch to yours?
I'm not making money from it, so trying to convince some random individual to use it is a waste of my time. Sure, I'll describe the features in the README and possibly include comparisons to other software, but I won't go out of my way to convince a specific rando just because they asked.
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.
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.
You're lucky if they even say that. Many public bug trackers I've seen are just filled with spam, entitlement and anger, demands/threats, or incoherent fever dreams of very unwell people. Forget about getting logs or reproduction steps. When you open bug tracking up to the public, you're lucky if what you get back is even remotely serious.
It's weird seeing people without computer familiarity using one, it feels like they are blind, they click in a button with a label and a icon, and when you ask todo it again they can't find it(even when you literally tell them the button name), it feels like their vision FOV is limited to a few centimeters, like those horror games flashlight lol, it's my own experience, but yeah, they aren't going to remember the error, or don't even read it, imagine print screen it before clicking "ok"
Yes, and some of the details really need to be emphasized, because I'm sure that a good chunk of people assume this means "people don't read more than they need to / people have a lack of inquisitiveness and general competence matching their lack of interest in reading for personal fulfillment" or whatever.
No, no, this is literal and (almost) not exaggerated. They _don't read_. Anything. _Ever_.
The almost-not-exaggeration is in the "ever", if anything, because some of these people can eventually be compelled, with much sighing and gnashing of teeth, to actually read something.
But as a matter of course, they don't read. And that's not just "don't read what they don't need to." It's more like, you know how your eyes happen across some text and you just read it inadvertently? And your daily life is full of moments where these glances at random words give you little reminders or flashes of insight or just fuel for the train of thought? Haha, that's a good one. I didn't even do that on purpose. Anyway, they don't do any of that shit, they literally have to start reading on purpose and the rest of the time, as far as I can tell, they are actually not processing any of it at all. They navigate the computer/phone by rote or by visual cue based on color/position of UI elements. When they can't figure out where to go using that method and you suggest that they actually, like, read the shit on the fucking web page they're trying to navigate, they ...
... start at the top left corner ...
... and crawl the page elements linearly ...
... and when they arrive at the correct one ...
... there's a pretty good chance that they won't actually recognize it as such, because for some reason they simply can't contextualize any of the shit they're reading!
These are people who have jobs and social lives, are not wards of the state, and can carry on a coherent, reasonable, and engaging conversation with you.
(No shade thrown to visual thinkers though -- there may be some overlap, but I don't run into these people as often as I run into visual thinkers, so I think I'm talking about something else)
But then I remember many interactions I've had with people while working with the public, and...yeah I believe it.
You're right. People simply don't read. They don't even notice there are words somewhere in their vision. I used to work at a water ride at a theme park, and people would ask if they'll get wet on it, and there would literally be a sign right next to me that said "You will get wet on this ride, you may get soaked".
And then, occasionally, I'd have someone read it out loud, slowly, "you...will...get...wet..." and then be like "I don't understand, will I get wet on this ride?" and they're not even joking. They can turn the letters into sounds and words, but can't comprehend the result, yet if I just repeated exactly what the sign says, they understand it fine.
Now I wonder how many people that struggled with "word problems" in math simply weren't literate to begin with.
My mom has been using Windows computers since before I was born. She would spend all sorts of time working on the computer, creating tests for her classes, researching my sister's illness on the pre-2000s internet (with great success even!), had no problem adopting software over the years as things upgraded and changed, had no problems pivoting to using a Macbook at work, had extremely few problems adapting to remote learning, to the point of asking me for advice using OBS to improve her ability to run a virtual classroom (for things like different "scenes" and control over her output video). She broadly understands the concept of "files" and directories and how to move them and transfer them and manage them well.
But at some point, she forgot how the "Start" menu worked! You put her at a Windows desktop and she doesn't know how to start the program she needs to use! Do you know how much goddamned money Microsoft spent ingraining the start button in people's heads in the 90s?
But it's just gone. Because modern web based stuff follows no patterns. It makes no sense. Shit just happens sometimes, with no feedback, with no warning, and sometimes breaks while only leaving a damn error message in the javascript console, and the behavior changes from one day to the next. The only way people who aren't experts can hope to navigate this hellhole is to learn EXACT workflows and never change them and never think of changing them and never attempt to do anything novel in case it breaks everything without warning and don't pay heed to any dialogs because they don't contain useful info anyway.
Like, what did we expect to happen when we punished people for trying to build mental models of this stuff? You cannot build simple mental models of webapps. Companies don't want you to, because then you might not be as bamboozled and you might be less susceptible to advertising.
If you're talking about non-technical users, they (a) don't even think of copying the error message, (b) don't know how to copy the error message, and (if the error message isn't directly copyable) (c) have no idea how to do a screenshot.
It cuts both ways. Guess what's one of the most popular format for apps and webpages to report failures to the user?
"Oops. Something went wrong."
Not exactly overflowing with useful information, either.
Sure, the system is probably logging the fault internally, and is always collecting metrics that help with contextualization later. But the system and its owner aren't usually the ones most affected by any given bug - it's the user who is. The user who's now worrying whether it means they're about to lose the time and work they put in the current session, or whether the app just ate their money (failures half-way through payment processes are the cutest, aren't they?). They don't know - maybe the "Oops!" was just benign, or irrelevant. Then again, maybe they've already lost it all 10 minutes ago - back when the previous "Oops!" briefly flashed to gently inform them that the service's back-end tripped over itself and died - but they won't discover that until later, at which point they'll be neither able nor willing to make a proper bug report.
Point being, if one sees their users as being 5 years old (but with parents' credit card in hands), one shouldn't be surprised to only ever get a kindergarten-level error reports like the ones you mentioned[0].
This is not just me complaining on a tangential issue - I believe showing specific and accurate error messages improves the ratio of useful error reports. It's not a full solution, but it's a step in the right direction. Treating them as partners, instead of a bunch of brats you have to put up with until they complete the payment, makes them more willing to reciprocate; giving users means to contextualize their experience allows some of them[1] to understand what's going on, and gives them something useful to put in the report too.
That, or I guess nowadays you can also keep the "Oops."-es, double-down on telemetry, and feed the metrics to a SOTA LLM to identify and interpret failures for your engineering/operations team, which we all know has neither time nor patience to do it.
--
[0] - "Page doesn't work" is the adult version of a kid suddenly starting to cry for unclear and possibly non-specific reason.
[1] - Obviously, not all, or even most. Software is complex, most users still behave as if half-drunk and unable to read, etc. Still, even 5 year olds can comprehend basic words and identify patterns. Figuring out that "could not connect to payment gateway" is serious, that "failed to write [blah blah tech terms]" that happens at random is probably not, etc. is within the cognitive reach of most users.
Yes, I love it. How helpful! I'm so lucky to have such a meaningful error message to Google. Now I only have to blindly try a list of 50 possible fixes before I discover that I couldn't save a replay on my XBox One because the disk was full.
Naturally, the stock counterpoint is that this happened because users thought real error messages were too scawy! :(
Counter-counterpoint: Oh well
Making simple, useless bug reports is easy and it will always be the easiest. Also the "my neighbour spies for the government" types will anyway always be the most motivated ones. There is no way to make it hard for "bad" reports without making it harder also for useful reports (barring some obvious cases of bots, ip filters etc, which are not what is discussed here and are a general problem not just for bug feedback). By trying to reduce the noise, you also reduce the signal thus get a worse SNR.
The specific tool is smart in trying to increase the signal. If you make it easier for users to add some useful context, MAYBE you get more users actually giving you sth useful, maybe even users who otherwise would not bother to add anything more useful than "it does not work".
I use software that recently made much simpler to make bug reports and add context, and they say they actually receive much better bug reports after. And most importantly, the users actually see that the bugs get fixed, which motivate them to make more, and more detailed, bug reports. Imo getting bugs fixed (and maybe even recognise the users' contribution in reporting them) is the best way to get good bug reports. Honestly, from my user's perspective having my feedback taken seriously is the best motivation for me to continue submitting reports. Because, honestly, sometimes bugs come up in complex situations that may be tricky to understand/reproduce, and it is hard to understand what context is relevant. I am not usually motivated as a user to spend like 20 minutes figuring out exactly how to reproduce a bug, but if I see that the company/engineers actually care and try to make it easy to me to report to them, I may actually do it.
Yes you are gonna have bad interactions also (and remember people have their own jobs/lives/not enough time to always engage with you the way you may want them to in providing feedback), but the point is to increase the good/useful interactions (compared to them), not decrease interactions in general. Unless you do not care much about bug reports anyway, that's also fine.
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.
The phrasing should be customizable. Even better if the bug is an SVG and I can paste in my own SVG for the bug icon.
I was worried about how it worked on mobile, and unfortunately on my iPhone I could not find a way to drop the bug where I wanted. It did show a popup eventually but it covers a lot of the page given it doesn't work as expected.
Just sharing thoughts/observations; I really like the concept as well.
I'm aware of the issue in mobile devices too, will push an update later tonight to fix it.
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.
It is an approach, for sure.
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.
I also just got a first response about a bug I reported 5 months ago,
It really depends on the author
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.
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?
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.
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 other method I used is to have audit logs, identify when there are errors in certain steps.