Bug tracking for a team of one to five

The real problem isn't forgetting bugs

Small teams rarely lose bugs because they lack a database. They lose them because bugs arrive through five channels at once: a message in chat, an email from a client, something a colleague said walking past, a note in someone's own file, a screenshot pasted into a group thread at 11pm.

Each of those is a perfectly reasonable way to mention a problem. Together they mean nobody can answer the only question that matters: what is currently broken? That question having a single answer is the entire value of a tracker at this size. Everything else is secondary.

Which leads to the rule that matters more than any tool choice:

A bug that isn't in the tracker doesn't exist. If someone tells you about a bug in chat, your job is not to fix it — it is to file it, then fix it.

Four statuses, and why not more

A status should represent a real handover — a point where responsibility moves. Add more than that and people stop updating them, at which point the field is worse than useless because it is confidently wrong.

The one people are tempted to drop is the gap between fixed and closed, because on a small team the fixer and the verifier are often the same person and it feels like ceremony. Keep it anyway. It is the only thing standing between you and a bug that was marked done, never actually checked, and shipped broken. On a team of three, "fixed" means "I believe I fixed it" — which is not the same as "it works".

Statuses you do not need at this size: triaged, confirmed, reopened (just set it back to open), won't fix and duplicate (both are closed, with a reason in a comment), and anything involving a review queue.

One priority field, not two

Large-team tooling splits severity and priority because the person who finds a bug and the person who schedules it are different people with different information. Below about ten people they are frequently the same person, so two fields set in the same moment always agree — you get the ceremony of triage with none of the information. One field, and describe the damage in the text. The full argument is here.

One discipline that does pay: cap the top level. If a third of your bugs are critical, the word has stopped working. Some teams cap it literally — no more than three open criticals, and raising a fourth means demoting one. It forces the conversation you were avoiding.

Fifteen minutes a week

Triage on a small team is not a meeting. It is one person, once a week, going down the open list and asking three questions of each bug:

1. Is this still true? Plenty of bugs get fixed incidentally. Close them.
2. Is the priority still right? Circumstances move; priority should move too.
3. Is anyone actually going to do this? If not, close it honestly.

That third question is the one small teams dodge, and it is the most valuable. A backlog of two hundred bugs nobody will ever fix is not a record of work; it is a pile that makes the fifteen genuinely important bugs harder to see. Closing a bug is not an admission of failure. Deciding not to fix something, out loud, is a decision — leaving it open forever is an absence of one.

What to skip

• Sprints. They exist to create a predictable planning cadence across multiple teams. With four people you already know what everyone is doing.
• Story points. Estimation exists to forecast capacity for people outside the team. If nobody is asking for that forecast, you are estimating for no reader.
• Custom workflows. Every state you add is a state someone has to remember to move things out of.
• Required fields. Every mandatory field is a small tax on filing. At this size, the risk is people not filing bugs at all — not filing them imperfectly.
• Separate boards per person. One list, filtered by assignee when you need it.

Bringing in people who aren't developers

Small teams almost always have people at the edges: a designer, a client, a contractor, someone doing support. They see the most bugs and file the fewest, usually for two fixable reasons.

Per-seat pricing. If the tenth occasional participant costs another hundred dollars a year, they don't get an account, and their bug reports arrive as chat messages instead. This is the single most common reason small teams end up with bugs scattered across channels.

No safe role. If the only options are full access or nothing, you cannot let a client in. A read-only role solves this: they see what is filed and what is fixed without being able to reassign or delete anything.

A tracker sized for this

Everything above describes how BugTrack is deliberately shaped: four statuses, one priority field, per-project roles including a read-only viewer, no seat pricing, and nothing to configure before you file your first bug. It is self-hosted on your own server with no database server to run.

If you outgrow it — a QA function, releases needing sign-off, several teams coordinating — you will want something heavier, and you should go and get it. Being the wrong tool for a fifty-person company is what makes it the right one for five.

Frequently asked questions

Can we just use a spreadsheet?

For a while. It breaks down when two people edit at once, when you want a screenshot attached to a row, and when you need to know who changed a status and when. That is usually somewhere around thirty open bugs or the second person.

Should bugs and features live in the same tool?

At this size, yes. Two systems means two places to check and two lists to keep honest. A label is enough to tell them apart.

What about bugs reported by customers?

File them yourself rather than giving every customer an account. Keep the customer's exact wording in the description — it is often more precise than your paraphrase — and note who reported it so you can tell them when it is fixed.