Jetlag
Plane, Share, Explore.
Client
Self initiated
Year
2026
Reach
N/A
Industry
Travel, Tourism
The product
A trip ends up scattered. Airline PDFs in one inbox, screenshots in another, the real plan somewhere in a group chat, and a calendar entry nobody updated after the dates moved.
Jetlag makes the trip the record everything attaches to. Cities, dates, the people coming, the flights and stays that get booked, and the documents that prove all of it, in one place that everyone on the trip can see and change.
I design and build it myself: the design system, the screens, the Supabase backend, the edge functions and the parsing pipeline.
The constraints
Several people plan one trip from different countries, and most of what changes is not text. A date moves, a city is added, someone joins a flight. Everyone has to see the same trip without it turning into a chat, and without one person's edit quietly undoing another's.
The app is needed most where the signal is worst. A boarding pass at a gate, an address in a taxi, a plan in a country with no roaming. Everything has to be readable with no connection, so trips cache to encrypted per-user files and open with nothing to fetch.
And some things cannot be shown honestly. Cached fares can't tell you what a specific ticket actually costs, and the only hotel API the partner offered was shut down industry-side. Rather than dress that up as a search result, those became hand-offs.
The work
It started as an itinerary and grew into the rest: planning a trip with the people on it, importing whatever gets booked elsewhere, and keeping all of it readable on a phone with no connection. Three parts are worth showing.
Trip Building
A trip is a name, a set of cities, dates that can be exact or approximate, and a crew. The planning flow walks through choosing destinations, setting dates, and deciding how many days go to each city.
Crew members are invited by username and get a push. Travellers without accounts, children or a partner who will never install it, exist as named guests with their own tickets and their own colour, so the trip is complete even when not everyone is a user.
The Journey
The trip page draws the whole trip as a vertical transit map. Crew avatars sit at the top, one line per traveller runs down through flight chips into each city's photo card and on to the next, ending back at the avatars.
The rules are what made it work: every traveller keeps one fixed column so lines never cross, elbows are orthogonal and share a height per row, and the curves around each city card are symmetric. Each traveller carries a colour or a print, fifteen in all, and the same one rings their avatar and accents their tickets everywhere else in the app. Legs with no booking show a plus node that every line converges into.
Ticket & Booking Imports
Almost nothing gets booked in one place, so a confirmation PDF has to become flights, tickets, passengers and sometimes a hotel, all attached to the right trip.
A server-side parser extracts the booking, then a reconciliation engine negotiates with the plan rather than overwriting it. It recognises round trips, multi-city bookings and connections, proposes shifting the itinerary when the dates have moved, offers to add or replace a city when the flight lands at a nearby airport, and spots a booking that belongs to a different trip entirely. Passengers match to crew by name, and the ones that don't can become guests.
The confirm step is a deck of cards ending in a single atomic commit, so nothing is written until the last tap and abandoning halfway leaves the trip untouched.
