Case Study: Menu Bar Time Tracker
A designer builds their first macOS app to solve their own problem.
The Project
What: A menu bar app for tracking time on design projects Platform: macOS (SwiftUI) Designer: UX designer, never wrote code before Timeline: One weekend
Why They Built It
“I tried every time tracking app and hated them all. I wanted something minimal — just show me what I’m working on and how long. No reports, no billing integration, no team features. Just a timer in my menu bar.”
The Result
A simple menu bar app with:
- Quick project selection
- Running timer display
- Start/pause/stop controls
- Basic history view
- Data saved locally
Key Prompts That Worked
The initial vision
I want to build a macOS menu bar app for time tracking.
Super minimal.
Features:
- Menu bar icon shows current timer
- Click to show list of projects
- Click a project to start timing it
- Shows today's time per project
- Saves data locally (just for me, no cloud)
Start with the basic menu bar presence and project list.Getting the timer working
Add the timer functionality:
- When I select a project, start counting
- Show elapsed time in the menu bar (HH:MM)
- Clicking again stops the timer
- Save the time entryMaking it feel native
It doesn't feel like a real Mac app.
Use SF Symbols for icons.
Match the system menu bar style.
The popover should feel native.Data persistence
Save all time entries using SwiftData or UserDefaults.
I want the data to persist when I quit the app.
Also save my list of projects.The Biggest Challenge
“The timer kept resetting when I clicked away from the popover. I didn’t understand why — I just knew the behavior was wrong.”
How they solved it
The timer resets when I click outside the popover.
I want it to keep running in the background.
What's happening?Claude explained the difference between view lifecycle and app state, then moved the timer state to the app level so it persisted regardless of the popover visibility.
What They Learned
- macOS has patterns — Following native conventions made it feel professional
- State is tricky — Understanding where data lives matters
- Small features add up — Each “simple” feature took more thought than expected
- Building your own tool is satisfying — Using something you made feels different
Prompting Insights
What worked:
- Being very specific about behavior (“When I do X, Y should happen”)
- Describing what felt wrong rather than diagnosing the problem
- Building features one at a time, not all at once
What didn’t work:
- Assuming Claude knew what “time tracking” meant without specifics
- Not describing the expected behavior clearly enough at first
Time Breakdown
| Phase | Time |
|---|---|
| Setup + menu bar presence | 1.5 hours |
| Project list + selection | 1 hour |
| Timer functionality | 2 hours |
| Data persistence | 1.5 hours |
| Polish + native feel | 2 hours |
| Testing + bug fixes | 1 hour |
| Total | ~9 hours (one weekend) |
See It
Screenshot or link would go here
Takeaway
“I’ve used this app every day since I built it. It’s exactly what I wanted because I built exactly what I wanted. No unused features, no clutter. And now I know I can build more tools when I have ideas.”