Turning trip spreadsheets into a guide for the road

On the road, I need the plan at a glance and the details at my fingertips

I plan every trip with Claude and keep the plan in a spreadsheet: each day, each stop, how to get there, what’s booked. That works at a desk. On the road I’m on my phone, and finding one row means zooming and scrolling sideways. What I need in the moment is simple: what’s next, how to get there, and what I need to know before I arrive, like what time the table is booked for.

Progressive disclosure keeps the day readable at a glance

Each day is a card with that day’s plan on it. The app opens on today and highlights what’s happening now. Tap a stop to see its notes and booking details, with the location underneath. On the go people scan rather than read, so the first screen answers what’s happening today and right now, and holds the rest back until you need it.

The moment that matters most on a trip is getting to the next place. You’re standing on a street in a city you don’t know, and you need to find the restaurant you booked and start walking. So I connected the app to the Google Maps API instead of building any of that myself. Each stop is matched to its exact place on Google Maps, so one tap opens it with directions ready. When I add a stop, Google suggests the exact venue as I type.

I’m building this as an MVP and changing it as I go, so I kept the scope to the core experience and didn’t build accounts or passwords. Sign-in is a link sent by email, using the login that comes with Supabase, and only emails on a short allowed list, my family and travel companions, can get in. The trip details stay private without any user management to build.

Two real trips exposed two failures: the wrong time and the wrong place

I used the app every day while in Vancouver and then in Ireland, and kept notes on everything that broke or slowed me down, the same way I’d run a usability test.

The first failure was time. The first version had Vancouver time built in, because it was made for that trip and Claude hard-coded it. In Ireland it ran eight hours behind, so it showed stops as current that had happened hours earlier. Now, when I create a trip, the app looks up the destination’s time zone through the Google Maps API and compares every stop with the local time there. Once I’m on the trip, it uses my phone’s time zone.

The second failure was place. A few map links opened the wrong spot, one of them an apartment building on another continent. My spreadsheet locations were written for me, with notes like “5-min walk east of Trinity”, and Google couldn’t match that text to a real place, so it guessed. Now the app cleans the text before it searches: it removes the notes, adds the trip’s destination, and saves the exact place Google finds. Every link after that opens the right spot.

To scale from one trip to every trip, I made any plan importable in seconds, with AI for the messy ones

The Vancouver trip proved the core experience worked, so the next step was using the app for every trip. Two things stood in the way. The first trip had been loaded into the database by hand, and my plans don’t come in one shape: some are my usual spreadsheet, some are notes pasted from a chat.

So I built an import with two paths. A spreadsheet in my usual format imports directly, with no AI, in a couple of seconds. For anything messier, I connected the app to the Anthropic API so Claude can read the plan. It pulls out each day and stop, marks anything it had to guess, and I check those guesses before they’re saved. I chose Haiku, Anthropic’s smallest and cheapest model, because my review catches its mistakes. Most plans take the fast path, and AI steps in only when it’s needed.

Once the API was in, Haiku took on two smaller jobs. When a plan changes and I have a free gap, it suggests up to three stops that fit between what comes before and after, and I pick one. And it names each day after what’s in it, updating the name when the day changes.

Fixing the format where plans are made puts most trips on the fast path

The fast path only works when the spreadsheet matches what the app expects, so I fixed it upstream, where plans are made. I had Claude update the guide my planning chats follow, so every plan comes out in the app’s format, with each location written as a venue and city that Google Maps can find.

Then I had Claude read my past trip-planning projects and pull out how I travel: what I prioritize, what I skip, how I like to pace a day. That became one travel agent that knows my preferences and writes plans in the app’s format from the start.

Next: connect planning to the app, and react to live traffic

Two things are next. First, connect the travel agent to the app, so a finished plan shows up as a trip without an import step. Second, use Google’s Routes API to check live travel times between stops. The travel agent already leaves enough time when it plans, but traffic and delays don’t show up in a plan. With live travel times, the app can tell me when to leave early for the next stop, and the free-time suggestions can use real distances instead of the model’s general knowledge.