Path

The idea

Most travel tools stop at the booking. Path starts after it, treating a trip as a sequence of small decisions made on the go. A super thin slice of this helped me plan my itinerary across Northern Kyushu, Japan, in April ‘26.

Each stop is a card holding where you sleep, what to do and how to get to the next place. The map ties them into a single line you can read at a glance.

What I actually needed help with

Japan is famous for having a complicated travel passes options, and I wasn’t immune. I had a little Claude skill that helped me plan that, but the idea with Path was that it would seamlessly surface relevant pass options to me, at the right time saving me from the endless search.

Every time I added a city I landed in the same r/JapanTravel threads: are passes worth it, which one covers which line, does it pay off for my route. Path notices that moment and puts the answer next to the city, as a small pass button on the result.

What’s in a map?

This is where I had the most issues whilst putting this together. The first version used a hosted basemap that needs an API key. When the key was missing or failed, the map loaded as grey tiles stamped “API KEY REQUIRED”, with the route floating over nothing.

Rather than keep patching keys and quotas for a concept, I drew the map myself: a coastline from open data, dotted land and the route on top. It loads instantly, needs no key and looks like part of the app.

Things I would weigh in a real build: how a failed map should look, what happens offline, and whether a stylised map stays clear when you zoom in to street level.