How I keep track of bugs and suggestions for six apps (with SnagFrog)

I make apps on my own, and I have more of them than is probably sensible. Cadence, Capta, Cleat, HourSlip and Retriever are all out in the world, and anyone using one of them will, sooner or later, find something wrong.

That part is fine. Bugs are going to happen. My problem was what came after: where the report ended up, whether it had anything useful in it, and whether I remembered to tell the person when I’d fixed it. With one app you can keep that in your head. With five you can’t, and I had stopped pretending I could.

So I built SnagFrog. This post is about how I actually use it day to day, because “I built a bug tracker” sounds like the start of a much more boring story than the one I’ve got.

What was wrong with the old way?

Mostly that there wasn’t one. A bug report was whatever someone typed, wherever they happened to type it. “The app crashed” with no version, no macOS version, no log and no screenshot. Then I’d write back asking for all of that, they’d reply a few days later (or not), and by then I’d forgotten which app it was about.

Suggestions were worse, because a suggestion never feels urgent. It got read, I thought “good idea”, and it went nowhere.

What I wanted was boring:

1. Every app has one obvious place to report something.
2. The report shows up with the details I’d otherwise have to ask for.
3. All of it lands in one list, across every app.
4. When I fix it, the person who reported it hears about it.

Getting reports in

Each app in SnagFrog gets its own report page at snagfrog.com/r/<app>. That page alone already helps, because it’s somewhere to link to. But the bigger win is putting the button inside the app, so people report things while they’re looking at them.

For a website or a web game it’s one line. This is what’s on capta.cam right now:

<script src="https://snagfrog.com/widget.js" data-app="capta" data-color="#ff6b81" async></script>

That adds a floating “Report a bug” button in Capta’s colour. When someone uses it, the report comes in with the page URL, the browser, the screen size and any recent console errors attached. Nobody has to type any of that, which is good, because nobody would.

For the Mac apps there’s a small Swift package. HourSlip pulls it in and adds “Report an Issue…” to the Help menu:

import SnagReporter

let snag = SnagReporter(
    appSlug: "hourslip",
    publicKey: "snag_pk_…",
    baseURL: URL(string: "https://snagfrog.com")!
)

NSApp.helpMenu?.addItem(snag.menuItem(logFiles: { [logFileURL] }))

Clicking it uploads the end of the log file, the app version and build, the macOS version, the Mac model and a snapshot of the window, then opens the report page in the browser so the person can write what went wrong. They can see what’s being sent and untick the logs if they’d rather not share them. I cared about that more than I expected to, because sending your logs to a stranger ought to be your call.

There’s also a Godot addon for games, which does the same thing on a hotkey.

One inbox

Everything lands in one inbox, whatever app it came from. Bugs, feedback and questions are separate kinds, so a feature idea doesn’t sit in the same pile as a crash. I set a priority, add a label if it’s useful, and move through the list with the keyboard: j and k to go up and down, e to close, / to search.

When I open a report, the log tail is right there with errors highlighted, along with the diagnostics and any screenshots. Most of the time I don’t need to ask the reporter anything at all, which was really the whole point.

Replies are real email. I write from SnagFrog, the reporter gets an email, and if they answer it, their answer threads back into the report. They also get a private link to follow the report without making an account. I didn’t want anyone to have to sign up for anything just to tell me my app is broken.

The bit I use most: Claude fixes it

SnagFrog has an MCP server, which means Claude Code can read my reports directly. You connect it once:

claude mcp add --transport http snag https://snagfrog.com/api/mcp --header "Authorization: Bearer snag_sk_…"

Each app in SnagFrog knows where its code lives on my machine. So I can open a terminal and say “fix the open HourSlip bugs”, and Claude lists the reports, reads each one with its logs, opens the right repository, makes the fix and runs the tests. Then it leaves an internal note on the report with what was wrong and what it changed.

It won’t email anyone unless I say “notify”. When I do, it writes to the reporter in plain words: what was wrong, that it’s fixed, and when they’ll get it. It leaves out file paths and stack traces, so it reads like a short note from me. If three people reported the same thing, it marks the duplicates and one reply reaches all of them.

A real one

The first report that went all the way through this was mine, which is a bit embarrassing. I was using HourSlip on the 1st of October and the invoice screen annoyed me, so I reported it from the Help menu like anyone else would. Three complaints: the date pickers were squished, the invoice options faded in in a weird way, and I had to scroll to see the invoice preview.

The report came in at 15:06 from HourSlip 0.16.2, with my macOS version, Mac model and screen size already attached, and I set it to low priority.

By 16:22 Claude had reworked the screen. The date pickers became proper buttons that open a calendar, the fade was gone, and the preview got its own column next to the details. All 222 tests passed. It left a note saying what it changed and sent the reply: the invoice screen is reworked, and the changes will be in the next update.

I looked it over, moved the layout around a little, and at 16:37 it shipped as HourSlip 0.16.4. Claude added one last note with the commit and the version.

That’s an hour and a half from “this annoys me” to a release. I didn’t write the reply myself, and it still read the way I’d want it to.

Not every report needs a code change. Just after midnight I sent another one, this time through the widget on capta.cam, saying Capta’s zooms were too quick. That’s a matter of taste as much as a bug, so it became a GitHub issue and a Linear issue straight from the report (SnagFrog does both), and the report got closed once it was tracked. Suggestions I’m not going to act on straight away still go somewhere I’ll see them, which is more than they used to get.

Is this overkill for one person?

Probably, a bit. But the thing I was really missing wasn’t a tracker. It was the details: the version, the log, the screenshot, and remembering to write back. Once those come along on their own, a report takes me a couple of minutes to deal with, or none at all if Claude handles it.

SnagFrog reports bugs about itself through itself too, which is either good dogfooding or a sign I need a hobby.

If you have more than one app and the feedback is all over the place, give it a try at snagfrog.com. There’s a 14-day free trial and you don’t need a card. And if you find a bug in it, you know where to report it.