Why I built another issue tracker

I still love Linear. That’s an awkward place to start an article about building an issue tracker, but it’s true.

I’ve used Basecamp, Trello, Wrike and plenty of others. I was VP of Marketing at Taskworld, where studying these products was part of my job. I loved working there. Linear became one of my later favourites.

For my personal projects, though, I couldn’t justify paying for it. The free plan’s 250-issue limit at the time kept getting in the way. GitHub Issues felt too thin for the way I wanted to work. I knew the sort of tracker I liked. I needed one I could keep using across my own projects.

Hydrant’s first commit was September 9, 2026.

The other people using the tracker weren’t people

I was also building with coding agents. Giving an agent a task in a chat was easy. Keeping track of what it had actually finished took more work.

This version of Hydrant started with a backlog in Markdown. That was enough to write down the work while there was no working tracker. Once Hydrant could hold its own issues, we moved the backlog into it and froze the old files as an archive.

The issue became the place to find the scope, the owner, the blockers and the evidence. An agent could read it before starting, leave the commands it had run, and explain what still needed a decision. Another agent could pick up the same issue without depending on the first chat staying open.

That changed what I needed from the product. Agents needed access to the same work I could see, through the same rules. If two of them tried to edit an old version of an issue, the tracker needed to refuse the stale write. If one said it was finished, I needed somewhere to check that claim.

A small product with a demanding first user

Much of Hydrant is built by agents, tracked in Hydrant. The feedback loop is fairly direct. A confusing issue field bothers the agents working on the next issue. A weak review process shows up in the product I have to use the next morning.

I still make the product calls. Sometimes I hand an agent permission to ship one specific issue. Sometimes I look at a technically correct screen and send it back because it feels unfinished.

I’m not trying to persuade everyone who likes their tracker to leave it. I wanted one that fit my projects, my budget and the way I was starting to build software. Now I get to use it while we make it.