A Show HN landed this week called Epiq — a distributed git-based issue tracker that lives in your terminal. Multi-user collaboration via per-user immutable event logs that converge in memory. No server. No web app. Your issues live where your code lives, version-controlled by the same primitive.
I almost scrolled past it. Yet another TUI. Yet another "we hate Jira" post. But the architecture line stuck: user-scoped immutable event logs that converge in memory. I've been running that exact primitive for the last few months in a different domain — agent memory — and the shape of the problems it solves is identical to what issue trackers have been getting wrong for a decade.
Worth saying out loud.
The problem isn't the UI, it's the boundary
Every issue tracker I've used puts work in one process and tracking in another. You write code in your editor, push commits via your terminal, and then context-switch into a browser tab to drag a card or write a comment. The friction isn't the dragging. It's the discontinuity — the moment where the artifact you're shipping and the record of why you're shipping it live in unrelated databases with unrelated change models.
For solo and small teams that boundary is pure overhead. You either skip the tracker (now your context is in your head, which doesn't scale past one person or one week) or you religiously update the tracker (now you're maintaining two source-of-truths and the cards drift the moment you stop policing them).
Epiq's bet is that the tracker should ride the same substrate as the code — git. Issues are events. Events are commits. Two collaborators converge by pulling each other's logs and replaying. The web UI doesn't disappear because it never existed.
That's the same bet I made when I built project-memory for my own agent stack. Memories, tasks, and decisions are user-scoped event-log rows in Postgres, written by Claude itself via MCP. The terminal session is the source of truth; the dashboard is a convenience read view. After a few months of running it, here's what works and what doesn't.
What user-scoped event logs actually buy you
The biggest win isn't sync. It's that deletion stops being a destructive operation. Every change is an append. The state at any timestamp is reconstructable. When I get something wrong — a memory that aged out, a task that was wrongly closed, a routine prompt I edited and regretted — I don't restore a backup. I append a corrective event. The "current state" view re-derives.
For a personal codebase or a two-person team that ratio is liberating. You stop being afraid of structural changes because nothing is structural, everything is replayable. Epiq inherits this for free from being git-native: every issue update is a commit on someone's branch, and merging is just history-aware union.
The second win is offline. The cards on my laptop in a tunnel are the source of truth, not a stale cache of a cloud system. When I land and pull, conflicts are events, not data-races. That matters more than most people remember once you're back in office wifi all the time.
Where event logs cost you
Two places.
First, queries that span "current state across N users" are non-trivial. Showing "all open issues assigned to Priya, sorted by last update" requires materializing the convergent state for every relevant log, then filtering. For five collaborators on one repo, free. For a fifty-person org with cross-team views, you're going to need indexes that look suspiciously like a traditional database. Epiq's TUI scope is the right scope for the architecture; pretending it scales to the enterprise tracker market would be a category error.
Second, the "right schema" for events is harder than the right schema for tables. Once your IssueCreated event has shipped to other people's logs, you cannot change its shape without a migration that also ships as events. I learned this with project-memory three weeks in when I tried to add a field to the memory event and had to write a migrator that synthesized backfill events for every existing row. It worked, but it was nine hours of work I would not have spent in a relational schema-migration tool. Plan for it.
The actually interesting question
If issue tracking can ride on the same substrate as code, what else can?
Project memory, obviously — that's what I'm running. Decisions and architecture notes, same. Daily standup logs, status pings, retro items — all of these are append-only event streams that benefit from converging on the same primitive as the artifact they describe.
The endpoint of this trajectory isn't "everyone uses Epiq instead of Linear." It's that the tracker stops being a separate noun from the repo, and what we currently call "project management" gets absorbed into version control the same way "code review" did when GitHub PRs ate Phabricator's lunch.
Epiq is a small thing. The primitive it picks is not.
If you're building anything that wants to record state-over-time for a small team and you'd otherwise reach for a SaaS — at least look at whether your storage layer could be commits on a branch instead. The migration cost is real, but the long-tail wins on offline, deletion, and replayability are real too. And once you've used a system where every undo is just append-another-event, going back to "ARE YOU SURE? this action is permanent" feels like a regression.
I'll be watching where Epiq goes. The author is shipping into a category that's been dominated by SaaS for so long the tooling muscle has atrophied. That's exactly the kind of gap where a small terminal-native tool with the right primitive can win a slice of the audience that was never going to pay Jira anyway.
Tools like this don't need to win Gartner to matter. They just need to make the next ten people who think "I shouldn't have to context-switch into a browser to update a status" build their own version on top of the right substrate.