How to Decide Which Bugs to Fix and Which to Cut

No game ships bug-free, and no team has time to fix everything, so one of the most important and uncomfortable skills in development is deciding which bugs to fix and which to consciously cut. Done badly, this means either burning your limited time on trivial polish while real problems linger, or shipping something embarrassing because you never drew a clear line. Done well, it means your effort goes to the bugs that most affect players, the ones that must never ship are never compromised, and the long tail of minor issues is honestly closed rather than pretended about. Here is how to decide which bugs to fix and which to cut, in a way that respects both your players and your limited time.

Weigh impact against cost

The fundamental decision is a trade-off between a bug's impact, how much it hurts players, how many it affects, how badly, and its cost, how much effort and risk fixing it carries, since your goal is to spend limited fixing capacity where it does the most good. A bug high in impact and low in cost is an obvious fix, while one low in impact and high in cost is an obvious cut, and the judgment is in the middle.

Thinking explicitly in these two dimensions, impact and cost, rather than reacting to whichever bug is loudest, is what makes the decisions sound, since it directs effort by value rather than by noise. A cheap fix to a widespread problem beats an expensive fix to a rare one every time, even if the rare one happens to be more annoying to you personally. Weighing impact against cost is the core framework for deciding what to fix, turning a sea of bugs into a prioritized question of where your effort buys the most player benefit.

Know what must never ship

Some bugs are not subject to the impact-versus-cost trade-off because they must never ship regardless of cost: crashes, data and progress loss, anything that blocks players from progressing, anything that breaks a core promise of the game. These are the non-negotiables, and the first step of deciding is recognizing them and committing to fix them no matter what, since shipping them does damage that no cost saving justifies.

Drawing this line clearly, a defined bar of severity below which a bug cannot ship, removes a whole category from the agonizing trade-off discussions and ensures the genuinely unacceptable is never rationalized away under deadline pressure. Everything above this bar gets fixed, full stop. Knowing what must never ship, and holding that line firmly, is the foundation beneath the impact-versus-cost weighing, since it guarantees the bugs that would genuinely betray players, the crashes and the progress loss, are protected from being cut for convenience, leaving the trade-off to govern only the bugs where cutting is legitimately an option.

Use occurrence data to judge impact

The impact side of the decision must be grounded in reality, not impression, so use occurrence data to judge it, the number of players actually hitting each bug, since impact is fundamentally about how many players a bug affects and how badly, and the occurrence count measures the how-many directly. Without this data, you risk fixing the bug that one vocal person mentioned over the one quietly hitting thousands.

Bugnet's occurrence grouping gives you exactly this, each bug with a count of how many players hit it, so the impact dimension of your decision is real rather than guessed, letting you see that a barely-noticed bug actually affects a huge number of players, or that a dramatic-sounding one is genuinely rare. This sharpens every fix-or-cut decision. Using occurrence data to judge impact is what keeps your prioritization honest, ensuring you cut the genuinely rare and fix the genuinely widespread rather than being swayed by which bugs happened to be reported loudly.

Fix the cheap high-impact bugs first

Within what is legitimately a trade-off, the clearest wins are the cheap, high-impact bugs, the ones that affect many players and are quick to fix, so do these first, since they deliver the most player benefit per unit of effort and clearing them fast improves the game noticeably for little cost. These are the bargains of bug fixing.

Prioritizing by impact-to-cost ratio, doing the high-impact cheap fixes before the high-impact expensive ones and long before the low-impact ones, maximizes the improvement your limited time produces, which is the whole point of prioritizing. It also builds momentum, since a run of cheap high-impact fixes visibly improves the game quickly. Fixing the cheap high-impact bugs first is the practical heart of good bug prioritization, ensuring your effort flows to where it produces the most player benefit fastest, which is how a small team makes the most of the time it has for fixing.

Be honest about won't-fix

The hardest part is cutting, consciously deciding that some bugs will not be fixed, but it is essential, since pretending you will eventually fix every minor bug clogs your backlog with false intentions and wastes attention. Be honest about won't-fix, explicitly closing the low-impact, high-cost, or simply not-worth-it bugs as decisions rather than leaving them to linger forever as imagined future work.

An honest won't-fix is a legitimate, respectable decision, not a failure, since spending your limited time on a trivial bug instead of a meaningful one would be the real failure. Closing these keeps your backlog a true picture of intended work and your attention on what matters. Being honest about won't-fix is what completes the fix-or-cut discipline, since deciding what to fix necessarily means deciding what to cut, and making those cuts explicitly and without guilt is what keeps your effort focused and your backlog honest rather than buried under a pretense of fixing everything.

Revisit decisions as data changes

A fix-or-cut decision is made with the information you have, and that information changes, so revisit your decisions as data changes, since a bug you cut as rare may turn out, as occurrence data accumulates, to affect far more players than you thought, flipping the decision. Treating decisions as revisable in light of new data keeps your prioritization accurate over time.

Your captured reports drive this, since the occurrence counts grow with use and can reveal that a bug deserves promotion from won't-fix to fix as its real prevalence becomes clear, or confirm that a cut bug truly is negligible. Watching the data lets the decisions correct themselves. Revisiting decisions as data changes is what keeps the fix-or-cut process responsive rather than rigid, ensuring that as you learn more about how bugs actually affect your players, your choices about which to fix and which to cut continue to reflect reality, which is the ultimate basis for spending your limited fixing time well.

You can't fix everything. Hold the must-never-ship line, weigh impact against cost with occurrence data, and cut the rest honestly.