We tracked bugs in a spreadsheet for two years. Here's what finally made us stop.

Why a spreadsheet seems like the right call

When you have three developers and a handful of bugs per week, the overhead of a dedicated bug tracker feels like a bad trade. You would spend more time setting it up than filing bugs. A shared spreadsheet is already open, everyone knows how to use it, and it takes about ten minutes to add the columns you need.

We are not going to argue with that logic. For a very small team in the early weeks of a project, a spreadsheet is fine. The problems come gradually, and then suddenly.

Where it starts to crack

Screenshots go somewhere else

A bug report without a screenshot is missing half the information. But a spreadsheet cannot hold screenshots in a useful way — you can link to a file somewhere, attach it as a Drive comment, or paste it into a cell and watch the row height explode. None of those options are good enough to be the default, so reporters stop including them.

Developers then have to ask. Reporters have to find the screenshot again. The round trip that a good screenshot would have eliminated takes a day instead.

Discussion lives in Slack instead of on the bug

"Hey, did you see row 47? I think it's the same as row 23." That message, and the ten that follow it, exist in Slack and nowhere else. Six months later, when the bug comes back, the context is gone. The spreadsheet row says "Fixed" and the fix was reverted in a refactor and nobody remembers why it was done that way.

A bug tracker keeps comments on the bug. That sounds obvious until you realise how much of your team's debugging reasoning is currently living in a chat channel with a 90-day message history.

Status updates are manual and lag behind reality

Someone fixes a bug and forgets to update the row. Someone else picks it up, spends two hours on it, and finds it was already closed. Or it was fixed in a branch that was never merged. Or the fix broke something else and was reverted.

Keeping the spreadsheet accurate is a discipline tax. Everyone intends to keep it up to date; nobody does consistently.

Sorting by one column breaks every other sort

You sort by priority to see what is urgent. Now the "fixed" bugs are scattered through the list. You add a filter. The filter hides a row you needed to see. You sort by date. The priority grouping is gone. Every view of the spreadsheet is a destructive operation on every other view of the spreadsheet.

The moment we switched

It was not a single moment. It was the fourth time in a month that a developer picked up a bug that had already been fixed, because the spreadsheet row said "In progress" and the fix was in a branch that never got marked done.

That fourth time, we sat down and added up the hours. Duplicate work, chased context, bugs reproduced from scratch because there was no screenshot. The spreadsheet was not saving us time — it was costing more than any tool we had dismissed as "too much overhead."

What we switched to, and why

We wanted something that would run on our own infrastructure — our code, our data, not a SaaS that would raise prices or shut down. We wanted screenshots in the bug itself. We wanted comments threaded to the issue. We did not want story points, sprints, or a configuration wizard.

BugTrack fits that. You download it, run two commands, and it is running. Bug reports have a description you can paste screenshots directly into, a status field someone actually updates because it is three clicks instead of finding the right row, and comments that stay on the bug forever.

The spreadsheet still exists. We use it for the things spreadsheets are good at: tracking release dates, mapping features to milestones, keeping a changelog. Bugs are not on it anymore.

When should you make the switch?

Not at the first sign of friction. If your spreadsheet is working and your team is small, leave it. Switch when:

• You find yourself saying "I think that was fixed" more than once a month
• Bug discussions are happening in chat rather than on the bug
• Reporters are skipping screenshots because attaching them is annoying
• Someone new joins the team and cannot understand the spreadsheet's conventions

Any one of those is a sign the tool is costing more than it saves.