Build the travel app you've always wanted
For years I've built a complex travel doc to organize the logistics of summer travel. This year I converted it into a rad travel app on a Saturday afternoon.
Every summer, before the big family trip, I make The Doc.
You might make one too. It's a Google Doc with a table. Flights up top, then hotels, then a row for every day: what's booked, the confirmation codes, who's going where and when. I hand a copy to my wife at the airport and it becomes the bible for the trip. In 2024 it ran us through the Croatian islands: Dubrovnik, Korčula, Split, a ferry every couple of days. In 2025 it ran Japan: Tokyo to Kyoto, a samurai lesson, a hedgehog café. This year it's a run through Boston, Croatia, Italy, France, and Maine. The Doc quickly gets messy.
Nevertheless The Doc works, but its kind of a tyrant. Every year it gets longer and smarter and harder to use. More links, more "[!] needs attention" flags, more places where the one thing you need right now is buried on page nine. This spring I caught myself building three competing layouts for the daily planner and labeling them, with no irony, FORMAT A, FORMAT B, FORMAT C.
That's when it clicked: I didn't want a better version of The Doc. I wanted something richer, more informative, and a little easier to navigate. What I wanted was an app. I’ve tried a bunch of apps theoretically made to do this, but none really worked for me.
So I built the one I wanted.
I didn't have to do manual iOS development to make this. That's the whole point. I built it using Antigravity the way you'd work with a sharp junior developer. I described what I wanted, in plain English, and my agents did the coding. (I used a mixture of agents including my home agent, Stella, who regular readers have met.) The Doc a real native app now, on my phone and my wife's. Mostly vibe-coded, but all mine. I guided and the tools built.
The bar for building things you just want for yourself is so much lower than you think. And the ceiling higher. Getting started is easy, crafting excellence takes time.
What The App actually does
The App knows what day it is. Open it on June 23rd (that’s today!) and it reminds me of the flight that I’m currently on. Open it on July 1st in Verona and the first thing you see is a reminder about our tickets to Aida, a map to the Arena with a link to a saved PDF of the ticket, and my note to "bring a seat cushion.” Open it on a travel day and it leads with your next transfer, a link to the train booking site and instructions on how to purchase tickets. The same screen quietly rearranges as the trip unfolds, adapting as needed to new information. (Remember, I wrote a whole post about just-in-time UX being the thing for 2026.).
Every day you also get the weather forecast, suggestions for meals and a selection of relevant phrases in the local language along with pronunciation audio. Hilariously, the AI added a phrase guide for Boston including: Wicked, Pisser and Packie. All useful phrases for the kids to learn for the camp bus tomorrow. Maybe the adults will hit a Packie after we drop the kids off.
The App has several touches that I really wanted in my app. It creates a detailed city guide for each place with useful information including a live map with your hotel marked, a brief about the history of the city, summaries of what it's known for, hints about local etiquette like tipping customs, relevant emergency numbers, and a selection of restaurants filtered so my wife (who doesn't eat seafood) never gets pointed at an oyster bar.
Since I work on NotebookLM, my favorite part (obviously) is that every city has it’s own podcast. I had the NotebookLM agent research the history, pull in the most relevant sources, and generate an audio briefing about the city. Little documentary-style episodes that ride in your pocket and play offline, right on the lock screen, while you walk around and explore a new place.
Here’s a small taste of Rovinj's audio briefing, "The Venetian Island That Became a Peninsula":
There's one catch: making those podcasts is the only step in this whole system I still do by hand. The notebook agent does the research and the generation; I'm just the one clicking through it, city by city. The day there's a NotebookLM MCP or API, this manual step can go away and the trip's audio will generate itself. (I'm choosing to hear that as a feature request. You're welcome, future me.)
A few more things The Doc could never do safely. It scans our passports and keeps the information in the iPhone’s secure storage: point the camera, and it reads the little machine-readable strip at the bottom and fills in the traveler information, while the photo itself never leaves the phone. The sensitive stuff stays sensitive, since passport numbers and document scans live behind Face ID in the iOS Keychain and never touch the network.
Both phones stay in sync without handing the cloud anything readable: when I update the trip back home, both phones pull the change, but the server only ever sees encrypted gibberish. The passphrase lives on our devices and nowhere else. Zero-knowledge sync, for a literal family vacation. Overkill? Maybe. I’ve never been accused of doing things half-assed.
The messy middle
I don't want to lie to you and tell you making this was a totally frictionless experience. Building with AI is mostly iteration, and the bugs are real and occasionally hilarious or annoyingly sticky.
It took me forever to get the agent to do a reasonably good job with the Liquid Glass styling and to get the padding right for the edges and cards in the experience. Almost as frustrating as debugging CSS, but maybe a bit more complex. I guess there isn’t enough training data on the liquid glass design system yet.
Content can be misunderstood as well. At one point an agent reading a rental-car confirmation dropped Portland International Airport, the one in Oregon, into a trip that goes nowhere near it. Two Portlands. Classic.
For awhile the app crashed every single time you hit play on a podcast, because the lock-screen artwork was rendering on the wrong thread. A genuine Swift concurrency gremlin that took reading an actual crash log to pin down. And a real chunk of my commit history is just me sanding the tells off the machine-generated UI until it stopped looking AI-built and started looking hand crafted.
None of that required me to use my computer science degree. It required me to be stubborn and curious enough to keep going. That's the actual work now — bring your ideas, your sense of taste, and don’t quit until you like it.
Where I'm landing (and a question)
Technically, we still have about an hour before we land in Boston. But on my mind is a question: How low is the floor for making something? "I wish this were an app" used to be the end of the sentence: a wistful thing you said and then didn't do. It isn't anymore. If you've got a real problem you actually care about and you're willing to iterate, you can build a tool that solves your problem. Not someday. This weekend.
Which brings me to something I'd love your read on:
The engine under this app is already generic. I built it so the trip is just a simple json data structure with one file and a folder of screenshots. Each unique trip is a different file; the app itself doesn't change, it just points to a different source of truth. Which means I'm basically one onboarding flow and a hosting system away from being able to let other people try it: point it at your upcoming trip doc, and have The App make your own custom version to take with you.
Should I? Is this a rad thing to share, a little app to fill with your own trip? Or is it the kind of personal tool that's better left personal? I made it for me, but maybe it’s good enough to share?
Reply and tell me. And if you've been sitting on your own "I wish this were an app," consider this your sign. Go build the rad thing. I want to hear about it.