Quick answer: Treat features and fixes as competing for the same capacity, protect a baseline of stability work so bugs never accumulate, and let impact data guide the split. Balancing features against fixes is a capacity-allocation decision, reserve enough for stability that the game never degrades, then invest the rest where it matters most.
Players ask for new features constantly, and they also expect the game to work. Both demands compete for the same finite development time, and tilting too far either way fails players: all features and no fixes leaves a buggy game, all fixes and no features leaves a stale one. Balancing player-requested features against bug fixes is one of the central ongoing decisions of running a live game, and handling it deliberately, rather than reactively, is what keeps both your stability and your momentum.
Features and Fixes Compete for One Budget
The honest framing is that features and bug fixes draw from the same pool of your limited time. Every hour on a new feature is an hour not spent on stability, and vice versa. Pretending you can do all of both leads to overcommitment and a game that is simultaneously buggy and behind on features. Accepting that it is a trade-off, an allocation of one finite budget, is what lets you make the call deliberately instead of lurching between the two.
This also means the question is not 'features or fixes?' but 'what split?' You are deciding how to divide a fixed capacity, and that division should be intentional, not whatever the loudest recent demand pulls you toward.
Protect a Baseline of Stability Work
The most important rule is to reserve a baseline of capacity for bug fixing that you do not raid for features, no matter how exciting the feature backlog gets. Bugs accumulate if ignored, and a game whose stability work keeps getting deferred for features degrades steadily until the bugs become a crisis. A protected stability allocation, some fixed share of each update, keeps the game from rotting underneath the new features.
Use your bug data to size and direct that allocation. Bugnet's occurrence counts show you how much real player pain is in your bug backlog, so you can tell whether stability needs more of your capacity this cycle or whether the bugs are well-contained and you can lean toward features. The data keeps the balance grounded in actual impact rather than guesswork.
Let Impact Guide the Rest of the Split
With a stability baseline protected, allocate the remaining capacity by impact. A high-occurrence bug hurting many players may outrank a niche feature request; a widely-requested feature may outrank a pile of minor cosmetic bugs. Compare the player impact of the top bug fixes against the player value of the top feature requests and invest where the return is highest, rather than treating all features as more exciting than all fixes or vice versa.
Make the trade-offs visible to players where you can. A public roadmap that shows both upcoming fixes and planned features signals that you are balancing both, and lets players see that their feature requests and their bug reports are being weighed together. Bugnet's roadmap pages let you show this combined plan, which both guides your own allocation and reassures players that neither stability nor new content is being neglected. Handled this way, the feature-versus-fix balance becomes a deliberate, data-informed plan instead of a constant tug-of-war.
Features and fixes draw from one budget. Protect a stability baseline, then invest the rest where player impact is highest.