A Claude Code case study.
My problem:
I have to take a lot of public transport, often with 2-4 legs, they’re different almost every time, and sometimes it takes 15 minutes longer or shorter than the default 1h I calculate (for the same event address), which often makes it stressful or make me arrive early. This always tells me how long it’ll take way before I have to leave. Additionally, when someone schedules a meeting directly into my gcal, it will prevent them to schedule smth during any existing events, but gcal doesn’t know that I have to travel and won’t be available then, but can’t be bothered to create 3 events for every 1 event that actually happens (and then delete or move 3 events for every 1 event that changes).
This system solves all of that automatically:
- it hooks into my gcal, fetches any events that have an address associated, then calculates the transit duration from [home address] to [event address] and creates a new event in the calendar of that duration
- checks every week for the next 2 weeks, every day for the next 2 days, 2h before any event for that event
- there’s also a [travel address] that overwrites the [home address] temporarily; this can get manually configured or fetched from any event called “TRAVEL: [whatever else]” and its duration and address
The process:
The first version of this was live super quickly and worked well (when taking aside sorting out permission issues for the API and having to wait a bunch for those to take effect), getting some issues ironed out and then adding in much more features took much more time, but overall was a fairly short project when only including active time.
I’ve first talked through everything with regular Claude (web) and once we settled on smth that seems good it created a very detailed prompt for Claude Code to get to work on.
My initial unfamiliarity with Google Console and some slightly deeper parts of Cloudflare also made this take extra time, but this is really incredible for quickly getting more used to such things. Whilst I’m very far from deep understanding, I’m at least somewhat familiar with these systems, which otherwise would just not have happened.
At some point, things briefly seemed to be falling apart as one feature introduced a bunch of other issues, as well as when I mangled a git command, then had to revert A LOT and try to sort out which changes were actually good and which ones not. Do commits more often to have more places to go back to!
So far this only works for me, but Claude suggested during the design phase that we could already keep multiple users in mind for the architectural choices, such that adding that option later (we’ll see) is possible without major reworks.