Time tracking apps are abundant and mostly over-built. A personal one that does exactly what you need, with your data in your control, is an afternoon.

1. The model

An entry has a start, an end, a project and a note. A running entry is one with no end yet. Everything else — daily totals, weekly reports, invoices — is derived.

Only one entry can be running at once. That constraint should be enforced, not assumed.

time-tracker.txt
Build a time tracker. Local-first, one page.

- Start and stop a timer against a project, with an optional note.
- Only one running entry — starting a new one stops the current one.
- Manual entry and editing, because I'll forget to start it.
- Today, this week, this month views with totals per project.
- Storage in <localStorage / IndexedDB>, in try/catch throughout.
- Export as CSV.

Handle: the tab being closed while running, the clock changing, an
entry that crosses midnight, and an entry left running for three days.

2. Handle the running timer properly

Store the start time, not an elapsed count. Then a closed tab, a sleeping laptop or a refresh doesn't matter — you recompute on load.

The three-day running timer is a real case. Prompt about it rather than silently logging 72 hours.

3. Entries that cross midnight

A session from 23:00 to 01:00 belongs partly to two days. Decide the rule — split it, or attribute it to the start day — and apply it consistently in every report. Getting this inconsistent between the daily and weekly view is a confusing bug.

4. Make the reports the point

Tracking is the chore; the report is the reason. Totals per project per week, roundable to the nearest six or fifteen minutes for invoicing, exportable as CSV.

Make starting a timer one click from anywhere, including a keyboard shortcut. Friction at the start of a session is why people stop tracking.