Backlog.md alternatives: the one difference that matters

If you went looking for a Backlog.md alternative, you probably found nothing. AlternativeTo's page for it is blank — "Unfortunately there are no alternatives to Backlog.md on AlternativeTo" — and the comparison sites underneath it are answering about a different product, Nulab's Backlog, which is not the same thing at all.

That blank is a cataloguing gap, not a real one. Search the category and most of a page comes back full of them. Here is what is actually out there, and the one difference between them that will change what happens to you.

The field

Every one of these keeps tasks as files in your repository, works offline, and is meant to be read by a coding agent as well as a person.

Start with the honest part. Backlog.md is the category. At 6,822 stars and 428 forks it out-stars every other tracker on that list put together many times over — add the whole rest of that column and you do not reach thirty — plus a web UI with drag-and-drop, a terminal kanban board, and MCP support. Nothing below it is a drop-in replacement for that.

If you want the tool most likely to still exist in two years, with the most documentation and the fewest sharp edges, stop reading — it is the first row. The rest of this page is about the one thing the star count does not decide.

The most-starred result is not a tracker

Search this category and the repository with the most stars on the page is not on the table above. ai-dev-tasks has 7,786 of them, and leaving it out needs a paragraph, because otherwise the star count decides something for you that it should not.

ai-dev-tasks is a set of prompt files: one that writes a PRD, one that turns the PRD into a task list, one that walks an agent through the list. There is no storage format, no binary, and nothing that holds state between sessions — the task list is whatever Markdown your agent wrote that day. It is a good thing and a genuinely popular one. It answers a different question than every tool above, and if you adopt it expecting to still have an organised, queryable board in three weeks, that is this page's job to warn you about and not theirs.

ai-trackdown earns the same warning from the other end. It is on the table, at 10 stars, and its README is the most confident document in this whole comparison — but its own note says the project provides templates and documentation patterns and that working CLI tools are being developed separately. It has not been pushed to since 2025. Treat it as a schema to borrow, not a tool to install.

The split

Ignore feature lists and there are only two designs here.

A file per task. The task is a Markdown file. Changing its status edits the file in place. What you open is the thing itself, and you can read it with cat, edit it in vim, and diff it in a PR without any tool at all. Backlog.md, tasks, pi-task-tracker and — loosely — trackfile work this way.

pi-task-tracker is the purest version of it. A task's status is not a field inside the file, it is which directory the file sits in — backlog, active, archive — so moving a task is git mv and nothing else. That is the design at its most honest: no projection, no tool required to read the board, and no way for the rendered view to disagree with the files, because there is no rendered view.

An append-only log. The task is not a file. It is the result of replaying every event that ever mentioned it, and what you read is a projection. trk keeps log.jsonl and renders TODO.md; kadence folds state from its events on read.

Everything else is packaging. This is the choice.

What a file per task costs

Two agents, or two people, touch the same task on two branches. Both edit the same lines of the same file. Git cannot reconcile them, so somebody resolves a conflict by hand — in a file that is supposed to be bookkeeping.

We went looking for how often that actually happens, across 8,396 merge commits in 130 public repositories using file-based trackers. Conflicts in task files hit 15% of those repositories. Of the conflicts, 89% were content conflicts — two edits inside one file — rather than the add/add kind.

Read that carefully, because it cuts both ways. Fifteen percent is not most repositories. If you are one team of three shipping one branch at a time, this problem may simply never arrive, and paying a projection step to avoid it would be a bad trade.

Backlog.md's answer, which is a real one

Its README does not ignore this. It tells you to work "one task at a time" — a single task per agent session, one PR per task — and notes that splitting tasks well lets each session run independently without conflicts.

That is a workflow answer rather than a storage answer, and it is worth taking seriously rather than scoring a point off. It is correct: if two agents never hold the same task, the conflict never happens. It costs nothing to implement. It keeps the property that the file on disk is the task, which is the single nicest thing about the whole file-per-task design.

Its weakness is the weakness of every convention — it holds exactly as long as everyone follows it, and it is abandoned under the conditions that produce the conflict in the first place, which is two agents running at once because you were in a hurry.

What an append-only log costs

The honest bill, because it is not free.

You lose direct editing. The file on disk is a log, not a board, so vim is no longer a supported way to move a task — you need the tool, and that is a real dependency where the alternative had none. The log only grows; both trk and kadence ship compaction for exactly that reason, which is complexity that file-per-task never has to carry.

And projection can lie. If the rendered view is a file that a command regenerates, it is stale between the change and the regeneration, and a stale board is worse than no board. trk makes this explicit with a render step.

What you get for it is that the concurrent case stops being a rule people follow. Appends to a log do not collide the way edits inside one file do. On our own three-branch spike — three people editing one task on three branches, merged in every order — the result was 0 conflicts. That is a small test on one tool, not a law of nature, and it is the number we have.

Append-only is not one project's idea

Worth saying plainly, because a comparison page written by anyone in the field should be suspected of arranging the categories to win: trk arrived at the same storage design independently, in Zig, and claims union-merging on concurrent appends so parallel workers can each close their own task. It has zero stars and no adoption to speak of. It is also not wrong.

If the append-only argument is right, it is right for trk too, and the honest version of this page says so.

The ten-minute version, if you would rather not take my word for it

None of this needs a real project, and you should not believe a comparison written by somebody in the category without checking the one claim it rests on. Take any two of these tools and an empty git repo:

1. Initialise the tool, create one task, commit.
2. Branch twice from that commit. On both branches, move the task to a different status — that is the case that matters, not two edits in different corners of the file.
3. Merge both branches back.

The file-per-task tool has two branches rewriting the same line of the same file, and the merge stops with CONFLICT (content) — which is not a metaphor, it is the exact class that was 89% of the conflicts in the study above. The append-only tool has two records that do not overlap, so both land.

Now the part a vendor would leave out. Neither tool resolved the disagreement, because it is a real one — two people said the task was in two places. What changed is where you meet it: file-per-task makes you settle it during a merge, with the tool's syntax in front of you and the reason for the change nowhere in sight. Append-only records both and folds to the later one, which means you can read afterwards that it happened. That is better, and it is not magic, and anyone telling you the conflict went away is selling.

Then run the same test with the two edits far apart — a status on one branch, a comment at the bottom of the file on the other. Git merges that cleanly for every tool here. That is the honest boundary of the whole argument, and it is why the fifteen percent above is fifteen and not eighty.

How to choose

• Sequential work, one agent or one person at a time. Take Backlog.md. The conflict problem is one you will not have, and you get a web UI, a kanban board and the only community in this category worth the name.
• Parallel agents on one repository. The storage design starts to matter, and a convention that everyone must follow is the part that breaks. Look at the append-only row.
• You want the file on disk to be the task, non-negotiably. File-per-task, and Backlog.md is the most mature of them.

The thing not to do is pick on the feature table. Every tool here can add a kanban view. None of them can change what their storage does when two writes land on one task, because that is decided by the format on day one.

---