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.
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.
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.
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.
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 other method I used is to have audit logs, identify when there are errors in certain steps.
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.
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.
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.
A) only pay for perfection and
B) experience zero friction or cost in moving services?
It is an approach, for sure.
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