Project· Updated May 2026

Most trips don't start in a travel app. They start in a forwarded booking email, a half-filled spreadsheet, and a group chat that pings everyone whenever someone finds a restaurant worth booking. By the time the trip rolls around, the plan lives in five places and on three phones, and somebody is screenshotting Google Maps so the rest of the household can find the hotel.
I built journeys.im because that mess was my mess. The wedge is consolidating what's already there — booking emails, the household Google Sheet, the WhatsApp thread — into one trip object the household actually shares. Once that's done, the agent can do useful things: surface restaurant openings near the hotel, run the day on the ground, produce a Wrapped reel after the trip.
Why pre-trip, not in-trip first
The obvious version of an AI travel app is the in-trip one — "I'm in Tokyo, what should I do tonight?" That's where the LLM looks magical in a demo. But the painful problem is earlier. Confirming a hotel and a flight is easy. Sharing them with the four people travelling with you, in a form everyone trusts, is the part that breaks.
So journeys.im leads with capture. Forward the booking emails to your household inbox, drop the Google Sheet link, paste the group chat. The agent parses every one of those into a single trip, deduplicated by PNR, with each traveller as a first-class entity. The in-trip companion only makes sense after that foundation is in place.
Why households, not individuals
The household is the right billing unit because the household is the unit doing the trip. One adult forwards the flight email. Another adult forwards the hotel. A grandparent flies in separately and forwards their own ticket. They all need to land on the same plan. Per-seat pricing wrecks the dynamic; household-tier pricing makes the right behaviour free.
It also unlocks the post-trip surface. A trip Wrapped that one person sees is a curio. A trip Wrapped that the whole household sees, with everyone in it, is shareable.