We are a two developer team who just release a web application to solve an issue in an existing online community. It was a rush job (we only had 3 weeks to get it done), but we pulled it off and we are fairly happy with the result. The issue starts with the fact that we expected about 300 users total, and quickly surpassed 1000 in 24 hours. This has easily become the largest application either of us have worked on (in terms of unique visitors per day).<p>So here is the crux of the issue. What is an acceptable ratio of bug reports to users? We are getting some weird reports that we can't reproduce (and I strongly suspect is a result of the unexpected speed of scale), so where is the line between we can write it off as "A billion proverbial monkeys at a billion proverbial typewriters will manage to find an edge case. It happens", versus "This is a chronic issue we need to prioritize".<p>We would love the input from someone who has experienced this before, as this is entirely new ground for the both of us.
I think you are going about this incorrectly. Do not prioritize on commonality as your user count remains small. Instead prioritize on severity then carefully examine each defect as they come in. You are either willing to work the defect or you aren't. There is no harm in marking an issue as <i>out of scope</i> or <i>won't fix</i>. Just be clear and direct with your users that you have plans for this application and those plans only move in one direction.
Do you have a centralized logging system in place e.g. Kibana to monitor bugs? This was a major turning point for my team. Without any visibility/stats it's hard to know what is even happening and thus what an "acceptable" rate of bugs might be.