billing-clients-without-guessing-hours
Ask most freelance developers how they arrive at the hours on an invoice, and the honest answer is some version of "I looked at what I got done and worked backward." That process feels reasonable in the moment. It's also almost always wrong — and not randomly wrong, either. It's wrong in one consistent direction: down.
Why memory-based estimates systematically undercount
Reconstructing hours from memory means reconstructing from whatever you happened to notice and remember. The problem is that a huge share of real project time doesn't register as memorable "work" at all. A twenty-minute detour chasing down why a test started failing after an unrelated change. The ten minutes spent rereading a client's vague feedback until it actually made sense. The stretch of time lost to a dependency update that broke three unrelated things.
None of that shows up as a line in your memory the way "built the login form" does. So when you sit down at the end of the week to estimate hours, you're not remembering your actual week — you're remembering the parts of it that felt like productive, nameable progress, and quietly dropping everything else.
Coding time isn't the whole job
This is worth stating plainly, because it's easy to unconsciously equate "working" with "typing code in the editor." In practice, a normal chunk of real project time happens outside the act of writing code entirely: reading through logs to understand a bug, switching to a browser tab to check whether a UI change actually looks right, running a manual test pass, reading documentation for an API you're integrating, or just staring at a failing build output trying to figure out what changed.
All of that is real work. None of it involves your fingers moving across a keyboard for more than a few seconds at a time. If a time-tracking approach only counts moments of active typing, it will systematically undercount exactly the kind of work that tends to eat the most unaccounted-for hours — debugging and verification, not typing.
The actual cost of underbilling
The math here is unforgiving. If your real work is consistently 15-20% higher than what you invoice — which is a common gap once developers start actually measuring instead of estimating — your effective hourly rate is quietly 15-20% lower than the rate you think you're charging. You're not giving your client a discount on purpose. You're giving away time you never counted in the first place.
Over a year of consistent freelance work, that gap compounds into a meaningful chunk of income that simply evaporates, invisibly, invoice by invoice.
What clients actually want to see
Most client pushback on hourly invoices isn't really about the number — it's about not being able to verify it. A flat "42 hours this month" with no supporting detail asks the client to trust a total they have no way to sanity-check. A breakdown by project, with dates and durations that map to actual activity, does the opposite: it turns the invoice from a claim into a record.
That distinction matters more than most freelancers give it credit for. Clients who ask hard questions about hours are usually asking because the number feels unverifiable, not because they suspect dishonesty. Verifiable data tends to make that friction disappear entirely.
How automatic tracking handles the "stepping away" problem
This is the part manual tracking and naive automatic tracking both get wrong in opposite ways. Manual tracking undercounts because people forget to log the messy, non-typing parts of the job. But a badly designed automatic tracker can make the opposite mistake — stopping the clock the instant you're not actively pressing keys, which would technically "punish" you for the exact debugging-and-verification work described above.
JustClock handles this with an adjustable idle timeout rather than a hard cutoff. By default, if there's been no activity in the IDE for 5 minutes, tracking pauses — so stepping away from your desk for a genuine break doesn't get billed. But that 5-minute window is exactly why switching to a browser tab to check how a UI change rendered, or tailing logs in a terminal for a couple of minutes while debugging, doesn't immediately kill the timer either. Short excursions away from the editor that are still clearly part of the same task get captured, not punished.
The threshold itself is configurable, starting from 1 minute up to however strict you want it, and it can also be turned off entirely — in which case time counts continuously for as long as a project is open, regardless of moment-to-moment activity. That's a meaningful dial to have control over: a developer who does a lot of manual QA or spends real stretches reading documentation might prefer a longer window or no idle cutoff at all, while someone who wants the strictest possible definition of "active work" can tighten it down to a minute. It's set at the account level, so it applies consistently across every project rather than needing to be configured per project.
None of this is about gaming a number upward. It's about making sure the definition of "working" matches how the work actually happens, instead of an arbitrary rule that only recognizes keystrokes as real effort.
Building a billing process around real data
A practical process, once you're working from actual logged time instead of memory:
- Track continuously, not retroactively. The value of automatic tracking disappears if you're still trying to reconstruct a week after the fact — let it run in the background across every project you touch, all billing periods included.
- Reconcile weekly, not monthly. A quick weekly glance at logged hours versus what you expected catches surprises — a project running long, an estimate that was off — while there's still time to flag it to the client, rather than at invoice time when it's too late to have that conversation productively.
- Attach the breakdown to the invoice, not just the total. Even a simple per-project summary changes an invoice from a number the client has to trust into a record they can actually review.
- Set your idle threshold deliberately, not by default. Decide, consciously, what counts as "working" for your kind of work, rather than accepting whatever a tool ships with.
- Keep enough history to spot patterns. A single month of data tells you about one month. A year of retained history lets you notice that, say, integration work consistently runs 30% over your estimates — which is far more useful going forward than any individual invoice.
The underlying idea is simple: an invoice built on real, continuously logged time isn't just more accurate for you — it's also easier for a client to trust, because it stops being a claim and starts being a record. That's a better position for both sides of the relationship, not just a way to recover a few extra billable hours a month.