Tripeaz

Tripeaz is a collaborative trip planner. You build an itinerary day by day, drop in the places you want to go, and everyone on the trip works on the same thing at once. It's live at tripeaz.app.

It's built for the trips you take with other people, whether it's family, friends, or a group, where everyone has ideas about different days. No product has nailed this experience. Plans end up scattered across individual and group chats, and nobody can find any of it three weeks later.

Group planning is the most acute problem, and it's the first part that I set out to solve. Before it there's the discovery, which I call dreaming, and after it there's the trip itself. Tripeaz is currently focused on the planning portion, but I'm rapidly developing the other parts.

Travel planning is becoming a crowded space. Many AI apps promise to plan your trip for you. Most of them are similar. You provide some details about what you want and trust that what comes back is the perfect itinerary. No matter how great the plan is, it often fails when there's more than one person planning. Someone wants a different activity. Someone found a new restaurant. Now you're back in a group chat.

Tripeaz isn't an AI trip generator. I built the planning portion with a focus on collaboration.

Every other case study on this site is about creating conditions for a team. This one has no team. I've been building this in partnership with Claude, so nothing stands between a terrible idea and me spending the weekend building it.

Instead of iterating through feedback from a team, I shipped Tripeaz while it was still rough around the edges. As a designer that goes against every instinct. I could see the flaws and knew where it fell short. It went out anyway, because a week of real feedback was worth more than anything. I think of it as the small cake. Not a cupcake. Not the wedding cake. Just a small cake that's fully baked, fully functional, and ready for the firehose of feedback.

I built it in public because staying close to the tools is the job now. AI is reshaping how products get made, and that is not something you can learn from a distance. Shipping something is how I can stay sharp.

Posting the work while it is still unpolished is uncomfortable. Twenty years of designing products trains you to present finished thinking. Show the rationale, show the tradeoffs, show the polish. Building in the open is the opposite. You share multiple iterations and let people tell you what's wrong with it.

It worked faster than I was set up for. Feedback arrived quickly enough that I had to build a workflow just to handle it, funnelling everything into a backlog so nothing got lost in replies and DMs. Day-by-day navigation shipped because people kept asking for it. That's the loop working.

What it didn't deliver was growth. I tested a little paid acquisition early to juice the numbers and it didn't work. Organic is the opposite of a shortcut. It's a culmination of a lot of small things that only compound if you keep doing them. You plant, and then you wait.

At Poe I led design for an AI product. That's not the same as building with AI.

The setup is Claude on a Max plan, and several git worktrees running at once so separate branches of work can move in parallel. One tree holds the shipped product, one an experiment, one the growth work, with agents running against each. I still make every product and design call myself.

The clearest win is maps. I wanted travelers to see their day laid out before they set foot outside. I worked through the service options and the implementation approaches with Claude, and the useful part was weighing each option against cost and expected growth, not only against what was technically possible. That's the conversation you normally wait days for. Then the first version shipped, I looked at it, and it was wrong. The rewrite started four hours later and the whole thing was rebuilt inside about thirty six hours.

The hard lesson was security. A review found the app enforced nothing on the server. My screens only ever showed my own trips, but that was just the interface. Underneath, anyone who knew how to get around it could read every trip in the database, and write to it. The UI looked right while the server checked nothing. That's now row-level security on every table, with owner, editor and viewer enforced at the database layer instead of in the interface.

The other one was scale. I wrote fifty sample itineraries across six regions. Writing fifty is easy. Writing fifty that are correct is a completely different job. So I ran the drafts past ten adversarial reviewers, each one told to refute rather than confirm, and they came back with roughly 150 corrections. A statue in a museum it had already moved out of. A Sunday lunch booked at a trattoria that closes on Sundays.

A lot of my time went into building tools for myself. A linter that runs before anything deploys. A deploy gate that runs lint, then tests, then smoke tests against the real backend. A publish gate, so a draft page can't reach Google before a human has read it.

Every tool I built was a trust tool, and that's the same work as building an operating model for a team: deciding what gets checked, by whom, and at which point it's allowed through. Design teams are going to spend the next couple of years rebuilding tools and processes for the AI era. That will be part of a leader's remit.

Tripeaz is live and I'm still shipping to it most days. The current work is growth, which is slower and less satisfying than building features: a browsable library of sample itineraries, crawlable pages, blasting on socials, and conversion work on the paths people arrive through.

I will continue to inch toward the dreaming part, the thing that happens before anyone opens a planner. There's a working prototype for it that isn't in the product yet, but eventually, I'll ship the small cake version.