I love using Linear. I also built Hydrant, an issue tracker.
That invites a tidy origin story: I got frustrated, discovered a fatal flaw, and built the thing that fixed it. I don't want to tell that story just because it would make the product easier to explain. Liking a tool and wanting to make something in the same category can coexist.
For me, the useful explanation is about having a say in the product's defaults. An issue tracker contains opinions about how work should arrive, what makes it ready and which information deserves space on the screen. Building one means taking responsibility for those opinions, including the ones that turn out to be wrong.
It doesn't mean the alternatives have failed.
Linear doesn't need to lose this argument
An easy pitch would be that conventional trackers are for people and Hydrant is for agents. That would be a poor description of Linear.
Linear has an official MCP server for finding, creating and updating work, including issues, projects and comments. It documents read-only access too. Its agent support includes delegated issues, comments and guidance, with a human retaining ownership of a delegated issue. Those are substantial product choices, not an absence of interest in agents.
I don't need to invent that absence to explain Hydrant. Nor do I need to claim that a feature is unique before it can matter to the product I'm building. Lists of issues are useful in more than one application.
The question I want to answer is smaller: what would I choose if I could shape the whole tracker around the work I want to keep visible?
A place for unfinished decisions
A ticket can be easy to understand and impossible to start. It can also be urgent and too vague to hand to anyone. I want those distinctions to survive contact with the interface.
Hydrant keeps status, refinement and blocking separate. The status says where an issue sits in the process. Refinement says whether its scope is clear; blocking records the prerequisites still in its way. Ready requires refinement, but it doesn't imply that the work is unblocked.
Imagine a task to add an export after another task settles the data contract. This is an invented example. The export's scope and acceptance checks could be clear while the prerequisite remains open. Calling it unready loses the useful fact that somebody has already worked out what it needs. Calling it available to start loses the dependency.
That is the sort of product decision I care about. It is small enough to look fussy until you need the distinction. I would rather discuss whether it helps than stretch it into a claim that everyone else handles work incorrectly.
There is a limit to what the interface can establish, too. A review stage doesn't prove that somebody reviewed the work. Hydrant's help explicitly says its review stages have no approval gates. A person or agent can write a convincing status update without doing the job. The tracker still depends on how people use it.
Bring an agent, keep the record
The boundary in Hydrant's manifesto matters to me: bring the agents you use, let them work through scoped access, and keep their changes in the same attributable history as human changes. Hydrant tracks work. It doesn't run the agents.
That leaves a useful separation. The coding client can be where an agent reads files and attempts a change. The issue can hold the request, discussion and evidence that someone else needs to pick up later. I don't want understanding the state of the work to depend on having been present in a particular chat.
Hydrant's access documentation makes another boundary explicit: assigning an issue to a named agent grants no access and starts no execution. Access comes through a connection with permissions. The assignment describes responsibility; it isn't a hidden launch button.
None of this makes an agent trustworthy by default. An attributable bad change is still a bad change. The history helps someone inspect what happened; it doesn't excuse careless permissions or replace review.
Owning the choice includes owning the cost
Building a tracker is an expensive way to have preferences. Every behavior I choose becomes something to explain and maintain. A smaller product doesn't get to skip reliability because its ambitions are modest. People still expect their work to be there tomorrow.
If all I wanted were somewhere to put tasks, using an existing product would be the easier decision. I wouldn't recommend building a tracker merely to avoid adapting a workflow. There has to be enough interest in the product itself to justify the work that follows the initial version.
Hydrant is still in active development. Its manifesto says so plainly. I want room to decide what belongs, use the result, and change my mind when a choice makes the work harder to understand. That is a reason to build, not evidence that anyone else should switch.
I can keep liking Linear while taking those decisions seriously in Hydrant. I don't have to turn admiration into a complaint to explain why I wanted to make something of my own.