Show HN: tmpo – Minimal CLI time tracker with auto-detection for developers | Hacker News Reader

Show HN: tmpo – Minimal CLI time tracker with auto-detection for developers

github.com

1 pointdylandevelops2 comments

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!

Open articleView on HN

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.

Thank you!

I'm thrilled that the Unix-y approach resonates with you, as that is exactly what I am aiming for!

And yes, you have hit the main tradeoff that I have and am currently struggling with. The auto-detection works great for "I'm in X project, working on X," but it doesn't work well for the exact cases you mentioned.

Right now, this is how I handle these types of scenarios:

1. Context switches in the same repo: I use the description field to differentiate: `tmpo start "Refactoring auth module"` `tmpo start "Fixing CSS bugs"`

    This has the same project name but with different descriptions. When you export for invoicing or just personal statistics, you can see this breakdown.

2. "Non-directory work" (meetings, research, etc): I use `tmpo manual` to create entries after the fact. `tmpo manual` (opens interactive prompt for project/time/description)

    Or I just run `tmpo start "Team standup"` from wherever I am and let it tag to whatever directory I'm in. This is obviously a bit janky.

To be honest, I am still working on solving this problem. I optimized for what I think is most "solo dev working in project directories" because that is my workflow; however, I'd love to get more feedback and contributors to help make it work for others!

A feature I am also working on currently is a category/phase system that can significantly improve tagging time entries.

What is your current workflow? Do you switch contexts within the same repo often, or is the non-directory work the bigger pain point?

Reply on news.ycombinator.com