Solace

Time tracking for freelancers

Most independent workers lose hours not because they work less, but because they forget to press start. Here is how timer-based tracking compares with reconstructing time from the work you already recorded — and how to choose.

The problem with timers

A timer only measures the time you remembered to measure. In practice a freelance day is fragmented: a fifteen-minute call, a context switch to a client Slack thread, a two-hour block of focused work, a review pass at 11pm. Every switch is a chance to forget to start or stop the clock, and the hours that go missing are almost always the ones you were genuinely working.

Timers also do not leave a trail. When a client questions a line item six weeks later, “the timer says four hours” is an assertion, not evidence.

The alternative: reconstruct from artifacts

Almost everything you do already leaves a timestamp somewhere. Reconstructing hours means reading those records and inferring the working sessions behind them:

  • Commits. Each commit is proof that work landed at a specific minute, on a specific branch, in a specific repository.
  • Calendar events. Meetings you actually attended, with real start and end times and attendee lists.
  • Chat activity. Client conversations in Slack, which capture the support, clarification and coordination work no timer ever catches.
  • Manually logged work. The tasks that leave no digital trace — in-app configuration, testing, training, ticket triage — recorded once, as they happen.

Turning timestamps into honest hours

A commit at 2:04pm does not mean one minute of work. The estimate has to model how coding actually happens, and it has to be conservative enough that you would be comfortable showing the method to the client. The approach Solace uses:

  • Group commits into a session while the gap between them stays under a break threshold (60 minutes); a longer gap starts a new session.
  • Cap the idle time credited inside a session (35 minutes) so a single long gap does not inflate the total.
  • Add a short ramp-up before the first commit (10 minutes) for the thinking and setup that precedes code, and a brief wrap-up after the last (5 minutes).
  • Count meetings at their scheduled duration, and chat at a measured per-message rate — excluding threads where you never replied at all.

Every parameter above should be visible and adjustable. A number you cannot explain is a number you cannot bill.

Which method should you use?

Use a timer if your work is a small number of long, uninterrupted blocks and your client expects nothing more than a total. Use reconstruction if your day is fragmented, if you bill weekly, or if you have ever had an invoice questioned. The two are not exclusive — reconstruction gives you the baseline, and manual entries fill the gaps it cannot see.

A practical weekly routine

  1. Connect your repository, calendar and client chat once.
  2. Log untracked work the same day it happens — it takes under a minute.
  3. At the end of the billing week, review the reconstructed hours day by day.
  4. Adjust anything that looks wrong, and note why.
  5. Issue the invoice with the supporting breakdown attached, not on request.