Like my other studies, I worked with Claude, but this was a different kind of work. The Spotify and Amazon pieces started from products that already exist, so I was rearranging things people already know. This one I built from scratch, out of my own frustration planning trips. I wrote the requirements from the things I keep wanting and not finding, then decided what the product should actually be. So most of what follows is decisions, not pixels. The screens are where they landed.
Planning a trip lives in too many places. Ideas and want-to-dos pile up in social saves, bookings sit in a calendar, places get pinned in a maps app, and none of them talk to each other. The calendar buries a day's plan in a notes field. The map turns a multi-day trip into a wall of identical pins. And the part I find hardest, no map can answer. I can see what's nearby. What I can't see is whether I can fit it in before my 7:30 reservation, because the map doesn't know I have one.
maybes holds the whole trip in one place: the things you've booked, the things you might do, and where you are. The name says it, a trip here is a list of maybes, not an itinerary. They're loose options you commit to in the moment, with a few fixed points to plan around.
The first version of the feasibility engine worked off dwell time. For any nearby place, it would estimate how long you'd spend there, add travel time both ways, and tell you whether you'd be back in time, labeled comfortable, tight, or at risk of being late.
I cut the dwell-time estimate. It was the weakest number in the system. Guessing that a museum takes 120 minutes and then telling someone they'll be 9 minutes late pretends to a precision the app doesn't have. Nobody stays exactly as long as a default says they will.
So I flipped it. Instead of guessing how long you'll linger, maybes shows the time you'd need to leave a place to still make your reservation, and how long you'd realistically get there. "Leave by 7:08, about 21 minutes there." The app answers the one thing it can answer well, whether you can get there and back at all, and leaves the rest of the judgment to you.
leave-by removes the dwell guess, but it still leans on a map provider's travel-time estimate, which isn't reliable everywhere. It's a better-framed estimate, not a certain one.
The requirements called for the same trip to render as a calendar, a schedule, a list, and a map. I pushed back on the month-grid calendar. A month grid is mostly empty space for a four-day trip, and it's the worst of the views on a phone.
I restructured it to three: map, calendar, and list, with the single-day schedule as a drill-down rather than its own tab. The calendar stopped being a month grid and became a trip-scoped overview: just the days of your trip, each showing what's on it. That works whether the trip is four days or two weeks. A long trip is where it pays off most, fourteen days at a glance so you can see which days are full and which are still open. Zoom out to read the trip's shape, tap a day to get into it.
The trickiest thing to teach without a tutorial is that a place lives in one of two states, sitting on your wishlist or attached to a day, and it's the same place either way, not a copy.
My first version cheated. Tapping "add" filed the place onto whatever day you happened to be looking at. It was clever but it was wrong, a hidden dependency that falls apart on a long trip. I replaced it with an explicit day picker that suggests a day based on the place's neighborhood but never assumes it, so the location informs the choice, but you still make it. And it's tap-to-assign rather than drag, since the app is meant to be used one-handed while you're walking.
The hardest calls were about what to leave out.
A user question forced a good one. When you tap "go," does maybes navigate you itself? In Korea, Apple and Google maps are noticeably worse than the local apps. So I split two jobs people lump together. One is estimating travel time, which the app does internally. The other is turn-by-turn navigation, which it hands off to whatever maps app you already trust. maybes keeps the planning and the awareness in one place and lets go of the navigation, which every phone already does well.
Real ratings need a paid data provider, which this didn't have, so they're the one thing the app is missing. It's also the thing I most wish it had. When I save a place off Instagram, I still want to know whether locals actually rate it or whether it just photographs well. The call I could make without a budget was to not fake it: no invented stars, just your own notes and saved posts for now, with real ratings as the first thing to add when there's money for a source.
A couple of things are still open. The map gets crowded as pins pile up, and I'm working out how labels should behave when a lot of them overlap. The bigger one is the leave-by feature itself. The times in these screens are placeholders, so the real test is whether the idea holds up once it's running on real travel-time data, not the stand-ins I used to show the concept.
A redesign starts from a product that already exists. This one I had to define before I could design it. The calls I cared most about were about what to leave out: the dwell-time guess, the literal calendar, in-app navigation, ratings. Each was easy to keep and harder to remove, and cutting them made the product clearer. Deciding what the product should be, not just how it looks, is the part I wanted to get better at.