The problem
Every existing time tracker assumes the developer remembers.
That assumption is the bug. Developers do not remember to start a timer when they start a feature, and they do not remember to stop it when they switch to fix a production incident. The result is either timesheets reconstructed from memory at the end of the week (low accuracy, high friction, billing disputes), or no time tracking at all (and a contracting income that depends on flat-rate guessing).
There is also a second problem that did not exist five years ago. AI-assisted coding sessions, in Claude Code or Cursor or Copilot, generate work product that is real and billable but invisible to traditional time tracking. A developer might do four hours of useful work in a Claude Code session that produces a single commit. That work needs to land in the same ledger as the rest of the day, automatically.
Constraints
Trust, accuracy, defensibility.
Time tracking that produces a billable invoice has to be accurate enough to defend in a client conversation. That ruled out heuristics that look "close enough" but cannot be audited. Every recorded interval has to trace back to a verifiable signal: a branch checkout, a commit, a Claude Code session boundary.
It also had to be lightweight. A time tracker that drains battery, slows the IDE, or requires the developer to babysit a UI is the same failure as the one we are replacing. The capture layer had to be invisible.
And it had to work across the developer's actual environment, not a curated subset. JetBrains, VS Code, terminal-only workflows, AI coding sessions outside the IDE entirely. The capture had to follow the developer.
Architecture decisions
The shape of the system.
Branch as the unit of time. Switch to feature/auth and the clock starts on that branch. Switch away and the clock pauses or moves to the new branch. The developer never starts or stops a timer. The version control system does it for them.
Multi-surface capture, single ledger. The JetBrains plugin captures IDE activity. The CLI tool captures terminal-only and AI coding sessions. The desktop app captures activity outside the editor. The web dashboard is the read and edit interface. All of them write to the same ledger over a documented API.
Local-first capture, server-side aggregation. Each capture surface writes locally first, syncs to the server in batches. This means time tracking continues to work offline, on planes, on the conference Wi-Fi that drops every six minutes. Sync is idempotent. Replays do not produce duplicates.
Postgres as the system of record. Branches, sessions, commits, intervals, projects, clients, invoices. The schema is normalized enough to support multiple aggregation views without re-modeling.
AI session boundary detection. A Claude Code or Cursor session is a contiguous block of activity in a specific directory, often without a commit at the end. The system detects start and end from process activity and from file modification timestamps, then attributes the block to the active branch.
Invoice generation as a deterministic transform. Given a date range and a project, the system generates an invoice line item per branch per day, with a summary derived from the commits on that branch. The developer reviews and adjusts before sending. No magic numbers, no LLM-generated billing language.
What we shipped
The current state.
Working JetBrains plugin and CLI tool, both syncing to a working dashboard. Branch-aware capture with sub-second accuracy on the IDE side, sub-minute accuracy on the CLI side. AI coding session detection working for Claude Code and Cursor. Invoice generation working for the simplest billing models (hourly, fixed milestone).
Early access users are running it daily, on real client work. Feedback is shaping the v0.5 release, primarily around the invoice review flow, the dashboard's filtering, and the desktop app polish.
The VS Code extension is in active build, scheduled for v0.5.
What we would do differently
The retrospective, as it stands today.
We would start with the CLI, not the JetBrains plugin. The CLI captures the broadest set of workflows and was the highest-value first surface. The JetBrains plugin was the easiest to build and shipped first. In retrospect, it was the wrong sequence for early adoption.
We would defer the desktop app. Most of the value is in the IDE plugins and the CLI. The desktop app addressed a smaller use case at higher build cost. Shipping it second meant it diluted the focus of v0.4.
We would invest earlier in the invoice review flow. Time capture is half the product. Billing is the other half. The first version of the invoice flow was thin and we are paying for it now in iteration cost.
Time tracking that follows the work, instead of asking the developer to follow the timer.