Htet Wai Yan SoeSOFTWARE · DEVOPS · INFRASTRUCTURECHIANG MAI --:--Book a call
Sheet N · NotesI open-sourced DoneWhen, the tracker I use to work with AI agents6 Oct 2026
← Writing

I open-sourced DoneWhen, the tracker I use to work with AI agents

AI agents build at lightspeed, and I cannot catch up by reading.

The chat is gone by morning. The commit says “fix”. A task is “done” because the AI said so. I hit this every day building backend systems with agents, so I built a tool for my own problem, and now it is open source: DoneWhen.

It is not another Kanban board. It is how I work with agents.

The 39-second tour: track the work, understand it at a glance, a human holds the gate, check it again later.

The loop

  1. Research, propose, plan. I talk it through with the AI until the spec is clear.
  2. The agent writes the tickets in DoneWhen. Each ticket is a full execution spec: goal, parts, implementation notes, acceptance tests, what is out of scope. It also has a done-when checklist. A big feature becomes an epic of tickets with blockers between them. I confirm the titles and the scope.
  3. I start the agents with /goal and leave. Overnight, or while I do other work.
  4. They build on a branch, test, and tick each item the moment it is met. They link the commits and write an engineering document with a Mermaid diagram.
  5. The gate. A ticket cannot move to In Review while one item is open. The server refuses the move. The AI cannot talk its way past a checklist. If an agent is stuck, it marks the ticket Blocked and writes why.
  6. Morning review. I open the review inbox. I do not read every line of code. I read the tickets, the documents and the diagrams, and I open the code only where it matters. Then I approve, or send the ticket back.
  7. Weeks later I check again. The commits, specs and checklists stay. Reopen one item and the ticket goes back to review.

Why a server-side gate

A rule in a prompt is a suggestion. A rule in the database transaction is a rule. The gate checks the checklist in the same transaction as the state change, with the criteria rows locked, so a concurrent un-tick cannot slip past. The agent can only move a ticket forward by actually meeting the criteria, and every tick is attributed to the actor that made it.

What it is

  • One Go binary with PostgreSQL, and a SvelteKit app. One container to deploy.
  • A built-in MCP server. Any MCP client works, including Claude Code and Codex.
  • A Claude Code plugin for browsing and starting tickets.
  • An installable PWA with live updates over SSE and Web Push, so the review inbox is on my phone in the morning.
  • Self-hosted, with workspaces as a hard boundary. AGPL-3.0.

I started it in July for my own AI-built projects, and I still run those projects on it. Now I think it is ready for other people.

Try it

Three commands give you a demo workspace with about 24 tickets in every state and three tickets waiting in the inbox:

docker compose up -d --build
docker compose exec donewhen /app/donewhen user you@example.com 'a-strong-password'
docker compose exec donewhen /app/donewhen demo

The repo has a quick start, a self-hosting guide and the AI workflow I use. The case study covers the architecture.

If you work with AI agents, what would you want from a tool like this? Open an issue on the repo, or email me.