Why start/stop timers don't work for most freelancers

Start/stop timers have a logical premise: record every minute you work, attach it to a client, invoice exactly what you tracked. On paper, it’s clean.

In practice, you forget to start it. You forget to stop it. You’re three days into the week with a two-hour gap you need to fill in from memory. You estimate. You underestimate, because that’s what people do.

This isn’t about discipline. It’s about how timers are designed.

The structural mismatch

A timer requires you to take deliberate action at the exact moment you’re most focused on something else.

You’re about to start a client call. Your mind is on the agenda, the context, the list of things to cover. Hitting a button in a separate app is the last thing you’re thinking about. You’re finishing a deep work session and your brain is still processing what you just built. Starting the next task is the natural continuation. The timer is an interruption that belongs to a completely different mental mode.

This is the design problem. Timers assume that time starts and stops cleanly at moments when you’re free to notice them. Freelance work doesn’t work that way. Work bleeds into other work. Client context stays active in your head long after the task officially ends.

The forgetting rate on timer entries isn’t an outlier. Freelancers who track honestly over several months consistently report that 25–40% of their actual worked hours never make it into the tracker. Not because they’re careless. Because the tool requires a behavior pattern that conflicts with deep focus.

The multi-client problem

Timers fail even harder when you’re working across multiple clients in a day.

You’re three hours into client A’s project. A message arrives from client B — not urgent, but it needs 12 minutes to answer properly. You go back to client A. What do you do with the timer? Switch it to client B for 12 minutes? Most people don’t. They absorb the time into whichever session was open and move on.

Those 12 minutes disappear from client B’s invoice. Do it twice a day with three clients and you’ve lost an hour. Do it for a month and you’ve lost 20 hours that were worked but never invoiced.

The hours that disappear this way are rarely large individually. A few minutes here, a half-hour there. That’s exactly what makes them so hard to notice and even harder to recover.

The retroactive reconstruction problem

When you realize you forgot to start the timer an hour ago, you have two options.

You can trust the last timestamp in the app and mark the start as the last time you stopped. Usually wrong — you may have taken a break, changed tasks, or handled something unrelated.

Or you can reconstruct the session from memory. Also usually wrong, but in a different direction. Memory of duration is systematically biased. Deep work sessions feel shorter than they were. Interruptions feel longer. People consistently underestimate focused time and overestimate distracted time.

This means retroactive entries are biased in a direction that costs you money. Every reconstruction shaves a few minutes off the honest number. Across a year, those small underestimates add up to real income left on the table.

Why switching apps doesn’t fix it

The obvious response is to try a different tool. Better reminders, a more visible interface, a quicker start button.

The problem isn’t the app. It’s the interaction model. Any tool that asks you to deliberately start and stop recording time at the moment work begins and ends has the same structural flaw. Pomodoro timers have it. Desktop apps have it. Mobile apps with widgets have it. The friction may be smaller or larger, but the core mismatch remains.

This is why the average freelancer goes through three or four tracking tools before giving up entirely. Each new tool brings a short burst of compliance — the fresh start effect — and then the same gradual decay. Busy week, missed entries, retroactive guessing, then abandonment.

What the calendar already captures

Here’s what most timer conversations miss: your calendar is already a time record.

Every meeting you put in your calendar has a duration. Every working session you block off has a start and end time. These events exist before the work happens — not as a retroactive log, but as part of your planning. You created them when you were organized, not when you were mid-task.

The method that actually works is simpler than any timer: add your client’s name in brackets at the start of each event. [Acme] Strategy call. [Bolt] Deep work — proposal. Every event tagged this way is a billing record. At end of month, every event for [Acme] is time for Acme. Nothing reconstructed from memory. Nothing lost because you forgot to hit a button.

This isn’t a new tool. It’s a naming convention on something you already use every day.

Timescanner reads those tagged calendar events and generates a billing breakdown by client — without changing how you use your calendar. It works with any iCal calendar: Google Calendar, Outlook, iCloud, Proton Calendar, Notion Calendar, Fastmail, and others.

The deeper point

Timers fail because they ask you to be in two places at once: present in your work and present in the act of recording your work. Those two things are in direct conflict.

The calendar approach resolves that conflict by moving the recording to planning time, when you’re in the right mode for it. When you block two hours for client A on Thursday morning, that decision is made with a clear head. You’re not interrupting deep work to make a note. You’re planning, and the billing record is a byproduct.

The question isn’t “how do I get better at using timers?” It’s “do I actually need them in the first place?”

Timescanner reads your calendar and generates billing reports by client, without changing how you work. Compatible with any iCal-compatible calendar.