How can developers and software teams track hours without piecing together the week on Friday?

Why do developers lose track of so many hours?

Programming happens in long stretches, but the day is full of interruptions: a colleague who’s stuck, a client calling, a production issue. After an interruption, you go back to coding—not to your timesheet.

It’s not the big blocks you forget, but the edges. You’ll remember the main project you worked on by Friday. The twenty minutes you spent helping another client? Probably not.

• Helping a colleague on a different project.
• A client call with a question that takes forty-five minutes.
• An incident that forces you to drop everything.
• Code review for a project you’re not building yourself.
• Digging through logs or documentation that was never a formal task.

How do you handle ten-minute support questions?

Small questions don’t take much time individually, but they add up. Whether you bill for them depends on the client: sometimes support is covered by a maintenance contract, sometimes you charge per quarter hour. But you always log them—otherwise, you won’t know what that contract is really costing you.

Decide with each client where those hours go—maybe to a ‘Support’ or ‘Maintenance’ project—and log them as soon as you’re done. If you miss one, a timeline that helps you find it later is useful.

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

Your work leaves a trail. A commit has a timestamp, a repository, and a message. A session in Claude Code, Codex, or Cursor shows what you were working on and for how long. Along with your calendar, these are the best clues to what you did on a given day.

They’re memory aids, not timesheets. A commit doesn’t show how long you spent, and an AI session left open isn’t time worked. Use them to build suggestions you can review, as explained in Automatic time tracking.

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

Can your AI agent log hours automatically?

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 can read.

1. Connect your assistant to your time tracker’s MCP server once and sign in.
2. Work as usual. When you’re done, just 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 isn’t sure about the client or duration, the agent will ask you.
5. The entry waits for approval, just like your other hours.

Aren’t tickets enough to track hours?

Tickets describe what needs to be done; hours show what it actually took. A ticket might be open for three days while you only spent two hours on it, and plenty of work never had a ticket. Tracking hours based on ticket status gives a distorted view.

What works: put the ticket number in your time entry’s description. Then anyone can link hours to the ticket without having to keep two systems in sync.

Why track hours on a fixed-price project?

With a fixed price, you’re not billing by the hour, but those hours decide if the project is profitable. If you don’t track them, you’ll only find out at the end that you blew the budget—and you won’t be able to estimate the next quote any better.

Set a budget in hours for the project and log time against it as usual, using 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 develops new software in the Netherlands, it may qualify for the WBSO, the Dutch R&D tax credit. RVO then requires time records that at least distinguish by day, by project, and by employee. How this works for software is explained in WBSO for software.