Show HN: tmpo – Minimal CLI time tracker with auto-detection for developers (github.com)

1 points by dylandevelops ↗ HN
Hi HN! I'm Dylan, and I built tmpo to solve a problem I had as a freelance developer.

I was tracking billable hours using Google Forms (yes, really). Every time I switched tasks, I had to manually fill out the project name, start time, end time, and description. After forgetting to log hours several times and losing money, I decided there had to be a better way.

tmpo is a CLI time tracker that gets out of your way:

- Automatically detects project names from git repos or .tmporc config files - All data stored locally in SQLite (no cloud, no login) - Simple commands: tmpo start, tmpo stop, tmpo stats - Export to CSV/JSON for invoicing - Cross-platform (macOS, Linux, Windows)

Built with Go for speed and easy cross-compilation. The entire project consists of ~5k lines of code.

Example workflow: cd ~/projects/client-website tmpo start "Fixing authentication bug" # ... work happens ... tmpo stop tmpo stats --today

It detects "client-website" from the git repo and logs everything locally.

The thing I'm most proud of: zero configuration required. It just works. But if you need per-project hourly rates for billing, you can add a .tmporc file.

GitHub: <https://github.com/DylanDevelops/tmpo>

I'm working on getting it on Homebrew, but you can also install it via pre-built binaries or build it from source.

Would love feedback on: 1. What features would make this actually useful for you? 2. Is the auto-detection too "magical" or is it helpful? 3. Any concerns about the approach?

Thanks for reading!

1 comment

[ 2.6 ms ] story [ 11.0 ms ] thread
Nice idea. I like the “local-first, no account” approach, especially for something as sensitive as time tracking. Auto-detecting the project from the git repo feels like the right level of magic to me. It removes friction without hiding what’s going on, which is usually the hard balance to strike in CLI tools. One thing I’d be curious about is how it handles context switches within the same repo, or work that isn’t tied to a directory at all (meetings, research, etc.). Overall, this feels very much in the spirit of Unix-y tools: small, focused, and composable.