How do developers and software teams track hours without reconstructing the week on Friday?

Why do developers lose so many hours?

Programming is work you do in long blocks, but the day is full of interruptions: a stuck colleague, a client on the phone, a production incident. After an interruption you go back to the code, not to your timesheet.

What gets lost isn't the big blocks but the edges. You'll still remember today's main project on Friday. The twenty minutes for another client, you won't.

• Helping a colleague on another project.
• The client who calls with a question that takes forty-five minutes.
• An incident that makes you drop everything.
• Code review for a project you don't build yourself.
• Digging through logs or docs that never existed as a task.

What do you do with ten-minute support questions?

Small questions cost little each and a lot together. Whether you bill them is a choice per client: sometimes support falls under a maintenance contract, sometimes you charge per quarter hour. But you always log them, or you don't know what that contract costs you.

Agree per client where those hours go, for example a ‘Support’ or ‘Maintenance’ project, and log them as soon as the question is done. If that doesn't happen, a timeline that finds the question later helps.

How do commits and AI sessions help you find your hours?

Your work leaves traces. A commit has a time, a repository and a message. A session in Claude Code, Codex or Cursor shows which problem you were on and for how long. Alongside your calendar, those are the best clues to what you did on a given day.

They're a memory aid, not a timesheet. A commit doesn't say how long you worked on it, and an AI session left open isn't time worked. Use them to build suggestions you check yourself, as explained in Automatic time tracking.

Mind privacy. Commit messages, file names and prompts often aren't meant for your manager or your client. Keep that data private and share only the hours with a short description. More in Privacy and AI context.

Can your AI agent log the hours itself?

Yes, if your time tracker has an MCP server. The agent you just fixed a bug with knows which repository and branch it worked in and which commits were made. At the end of the session it can log that time, with a description a client could read.

1. Connect your assistant to your time tracker's MCP server once and sign in.
2. Work as usual. At the end, ask: ‘log this’.
3. The agent sends a description, the repository, the branch and the commit subjects, not code or file paths.
4. If the tracker is unsure about the client or duration, the agent asks you.
5. The entry waits for approval, like your other hours.

Aren't tickets enough to derive hours from?

Tickets describe what needs doing; hours describe what it cost. A ticket can be open for three days while you spent two hours on it, and plenty of work never had a ticket. Deriving hours from ticket statuses gives a skewed picture.

What does work: put the ticket number in the description of your time entry. Then anyone can link the hours to the ticket without keeping two systems in sync.

Why track hours on a fixed-price project?

On a fixed price you don't bill the hours, but they decide whether the project makes money. If you don't track them, you only find out at the end that the budget was blown twice over, and you can't estimate the next quote any better.

Give the project a budget in hours and log against it as usual, with a non-billable activity if those hours aren't billed separately. Check weekly how much of the budget is used, not just at delivery.

If your company builds new software in the Netherlands, it may qualify for the WBSO, the Dutch R&D tax credit. RVO then asks for time records that at least distinguish per day, per project and per employee. How that works for software is in WBSO for software.