Quick answer: If players can hit bugs in your released game, yes, you need one, but a player-facing tracker, not a developer issue tracker. Once reports come from players instead of just you, scattered notes stop working and a real system pays for itself.
"Do I need a bug tracker?" really depends on where your game is. Before release, when you're the only one finding bugs, a list might do. Once players are involved, the question answers itself: you need somewhere reports land with context, grouped and prioritised, or things fall through the cracks.
Before Players, You Might Get By Without One
While you're the only person hitting bugs, your needs are modest, a list, a notebook, a text file can hold what you find, because you have all the context in your head. At this stage a heavyweight tracker can be overkill, and a simple list is a defensible choice.
That said, even solo, the moment you're juggling more than a handful of issues, some structure helps you not forget things. But strictly speaking, pre-player, you can survive without a dedicated tracker.
Once Players Report Bugs, You Need One
Everything changes when reports come from players. Now bugs arrive without context, the same issue gets reported many times, and you can't tell what's widespread versus rare. A spreadsheet drowns fast. This is the point where you genuinely need a tracker, specifically one built for player reports.
Bugnet is that kind of tracker: player reports and crashes flow in with device and version context attached, group automatically by issue, and rank by how many players are affected. It's the difference between drowning in scattered messages and working a clear, prioritised list.
Pick a Player-Facing Tracker, Not a Dev One
Note the distinction: a developer issue tracker (for your own to-dos) is different from a player-facing bug tracker (where player reports land with context). Indie games specifically benefit from the latter, because the hard part isn't listing your own tasks, it's capturing and making sense of what players hit.
Bugnet is built for that player-facing job, in-game reporting, automatic crash capture, grouping, and even public pages players can see. If your game has players, that's the kind of tracker you need, and the answer to the question is yes.
If your game has players, you need a player-facing bug tracker, not just a dev to-do list. Pre-players, a simple list can do; once players report, scattered notes break.