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.
maybes doesn't have one obvious competitor. What it competes with is a workaround: places saved in Google Maps, bookings in a calendar, a few screenshots, and the rest held in your head. Each real tool does one slice of the trip well and drops the part that matters on the ground.
| what they use | saved places | reservations | live location | leave-by, in the moment |
|---|---|---|---|---|
| Google / Apple Maps lists | ✓ | – | ✓ | – |
| Calendar (Google / Apple) | – | ✓ | – | – |
| TripIt | – | ✓ | – | – |
| Wanderlog and trip planners | ✓ | ✓ | ~ | – |
| Instagram / TikTok saves | ✓ | – | – | – |
| maybes | ✓ | ✓ | ✓ | ✓ |
The planners come closest. Wanderlog and TripIt both hold a whole trip, but they're built for the desk before you go, optimizing a route or parsing a confirmation email. None of them connects your live position to the reservation you've already booked, which is the one question you have standing on a street with an hour to kill before dinner.
A maps app knows where you are but not that you have a 7:30 dinner. A calendar knows the dinner but not the four cafés you saved or where you're standing. maybes is the only one holding both at once, so it's the only one that can answer "can I fit this in, and when do I leave." That's the gap, and the product lives in it.
One product, said the same way everywhere. The tagline carries the feeling and the positioning carries the argument. Three pillars under it carry the proof, and anything I'd put in an ad or an App Store listing ladders up to one of them.
your not-really itinerary.
For travelers who save more places than they'll ever map, maybes is the in-trip companion that knows both where you are and what you've already booked. So it can tell you what's worth doing right now and when you have to leave. A maps app and a calendar each hold half of that. maybes holds both.
Saves, reservations, and your live location over one map, calendar, and list.
"not five apps and a group chat."
The leave-by time is tied to your next reservation, so "near me now" only shows what you can actually fit in.
"the map that knows your dinner plans."
A few fixed anchors, the rest left open. You commit to a place in the moment, not at a desk weeks before.
"a list of maybes, not a schedule."
What maybes never says is as fixed as what it does. It doesn't promise to plan the trip for you, surface places you haven't saved, or replace the maps app you navigate with. Those are real products, and claiming them would make the one honest promise harder to believe: fit your own saves around your own reservations.
maybes is a concept, so this is how I'd take it to market, not a live plan. The positioning and message above point it: the product rides on the saving people already do, asks no one to plan more, and demos itself. So the plan is to meet the saving where it already happens and let the leave-by countdown do the selling.
The person who feels this most saves dozens of places a trip and maps none of them, and likes a couple of things booked with the rest of the day open. They feel the pain sharply, and they already make travel content, so they're both reachable and the ones who spread it.
Meet the problem where it already lives. The saves happen on Instagram and TikTok, so the demo belongs there: short POV clips and screen-records of the leave-by countdown, led by creators who post real itineraries rather than ads. The clickable prototype plus a waitlist is the always-on proof. I'd hold off on Reddit's travel subs, which punish anything that smells like promotion, and skip paid while it's still a concept.
The product demos itself, so I'd lead with the moment, not the pitch: "POV: 90 minutes before your dinner reservation in Seoul," then the screen ranking nearby saves with leave-by times. The "can't make it back" warning is the relatable gut-punch.
The region follows the testers, not the other way around. Seoul is only the demo because that's where the last trip was. I'd open a waitlist to learn who's interested and where they travel, pick the first region from who signs up (most likely US-first, where the map and ETA data is strongest), seed creators who travel there, then widen region by region. Matching the launch to good map data keeps the leave-by honest, so it's a product call as much as a marketing one.
The value isn't how many places you check off. It's that the trip is easier to enjoy because the "what now?" problem is handled. So the metric chases that, not a checklist.
Active-on-the-ground trips: the share of trips where someone opens "near me now" while they're out and acts on it, tapping through to a place or handing off to navigation. That moment is the whole reason the product exists, so it's the truest sign it worked. A satisfaction score can't measure "less stressful," and a packed checklist is the wrong goal, since a stuffed day isn't a good day.
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.