How Freelancers Can Track Bugs Without Jira

Jira is a reasonable tool for a team with a backlog owner. It is a bad daily driver for a solo freelancer who already context-switches between three codebases.

You still need bug tracking. "It's in Slack somewhere" is not tracking. It is how production issues return two weeks later with "I thought you fixed that."

Here is a lightweight system that takes bugs seriously without enterprise ceremony.

Capture has to beat the chat window

Most freelance bugs are born in a voice note or a "quick one" message.

Rule: if it is a defect, it leaves chat.

Ask for (or write down):

• What they did
• What they expected
• What happened
• Where (URL, env, browser, device)
• Screenshot or short recording if UI

You can collect this in a template and paste it. If the client will not write it, you write it after the call. Unreproducible "it's broken" tickets are how afternoons vanish.

Keep the bug next to that client's work, not in a global pile and not in a different app from today's tasks. Hunting is how generic PM tools fail even when they have a "bugs" feature.

Fields you actually need

Skip story points, sprints, and 14 statuses.

Use:

| Field | Why | | --- | --- | | Summary | Future-you can scan it | | Client / project | You have more than one | | Steps / expected / actual | So you are not guessing | | Environment | Staging vs production lies | | Priority | P0 production vs "annoying" | | Status | Open, waiting on client, done |

That is enough to triage without becoming a Jira admin.

Statuses can be three: open / blocked / done. "In progress" is often a lie you tell the board.

Priority without a committee

Solo priority:

1. Production down or data wrong - today
2. Launch blocker - this week
3. Ugly but usable - scheduled, not "when I feel guilty"
4. Nice polish - backlog, not today's three

If everything is P1, nothing is. Put at most one production fire on today's plan. The rest wait.

A weekly bug sweep

Friday, 20 minutes:

• Close what is actually shipped
• Ping the client on anything waiting on them
• Confirm nothing urgent is only sitting in Slack
• Promote one lingering bug onto next week's plan if it still matters

Forgotten follow-ups are how small bugs become relationship problems. The sweep is cheaper than the apology.

What about GitHub Issues?

Fine when:

• The client is technical
• The repo is the agreed home
• You still copy chat bugs into issues the same day

Not fine as the only system when bugs live in five client Slack workspaces and you never open the other org's Issues tab. Tool-switching on top of codebase-switching is the same tax as context switching.

The bottom line

Track bugs without Jira by:

• Getting them out of chat
• Using a short field list
• Scoping by client
• Putting them beside today's work
• Sweeping weekly

You do not need sprint poker. You need to not lose the thread.

WorkFocus keeps bugs next to the client project and the daily plan so they do not live in a separate universe. If that is the gap in your stack, try WorkFocus free.