Wanderlist: turning travel memories into structured data

The problem: your travel history lives nowhere

Ask someone how many countries they've been to and you'll usually get a pause, then a count on fingers, then a hedge. "Twenty-something? Does a layover count?"

That pause is the whole problem. Travel is one of the few things people genuinely want a lifelong record of, and it's one of the worst-recorded things in most people's lives. The evidence is scattered across systems that were never designed to hold it: ten thousand photos in a camera roll sorted by date and nothing else, boarding passes in an airline app that purges history after a year, a hotel confirmation buried in email, a note on someone's phone titled "countries" that hasn't been updated since 2019.

None of those are a record. They're artifacts. A photo tells you that you were somewhere, but you can't ask a camera roll "which airports have I connected through more than twice" or "how many countries did I add last year" or "what was the longest flight I've taken." The data exists — it just isn't data yet.

Wanderlist exists to fix that: to give someone a real, structured, permanent record of where they've been, and to make adding to it fast enough that they actually keep it up.

What Wanderlist does

Wanderlist is a native iOS app for tracking your travels. You log the places you've been — countries, cities, airports, and individual flights — and the app turns that into two things: a map that fills in as you go, and a journal you can write into per trip.

The map is the emotional payload. A world map with your visited countries shaded in is instantly legible in a way a list never is. You see the shape of your life's movement: the continent you've covered thoroughly, the one you've barely touched, the corridor between two cities you fly constantly. People screenshot it. That's the point.

The journal is the part that makes the record worth keeping decades from now. A country count is trivia. "Three days in Lisbon, the week the flight got cancelled and we drove to Sintra instead" is a memory. Tying free-form writing to a structured trip means the entry has a date, a place, and a position in your history attached to it automatically, so you never have to reconstruct the context later.

And the flight log is the piece that makes it feel serious rather than decorative. Airports and flight legs are the atomic unit of how modern travel actually happens, and they're the level at which the data gets interesting — routes, repeat airports, connections, distance.

The real work: modeling travel as data

The hardest and most interesting part of building Wanderlist wasn't the UI. It was deciding what a "trip" is.

That sounds like a trivial question until you try to write the schema. Consider what a travel record has to represent:

• A country is stable and countable, but "visited" is ambiguous. Does an eight-hour layover in an airport you never left count? Different travelers answer differently, and both answers are legitimate — so the model has to be able to distinguish between them rather than pick one and impose it.
• A city is a place with coordinates, but the same name exists in many countries, and city boundaries are fuzzy. The model needs stable identifiers, not typed strings.
• An airport is the cleanest entity in the whole system, because the industry already solved it: airports have unique codes, fixed coordinates, and a known country. If you get airports right, a lot of the rest of the data model falls out of them for free.
• A flight is a relationship — an origin, a destination, a date — and it implies facts about everything else. A flight from one airport to another means two airports visited, potentially two cities, potentially two countries, on a specific date, in a specific order.
• A trip is a container with fuzzy edges. Is a two-week Europe run with five cities one trip or five? Users will say both.

The design decision that makes the whole thing work is treating flights and places as the primary records and letting derived facts be computed rather than stored. Country count isn't a number you keep and increment — it's the answer to a query over your places. Same for airport counts, cities per country, trips per year. Storing derived values is how travel trackers end up with a map that disagrees with the list on the next screen; computing them means every view of your history is consistent by construction, and adding a new statistic later is a new query rather than a migration.

The other decision worth naming: entering data has to be nearly frictionless, because the app only has value if the record is complete. A travel log with half your trips in it is worse than useless — it's actively misleading. So the entry paths lean on the structure: pick an airport and the country comes along with it; log a flight and both endpoints get recorded at once. Every field the user doesn't have to type is a trip that actually makes it into the record.

Why native iOS was the right call here

I'm not dogmatic about native. Plenty of products would be better served by a web app that's live everywhere in one deploy, and I'll say so when that's the case. Wanderlist isn't one of them, for three specific reasons.

It's offline by necessity. The single moment a travel app is most likely to be opened is on a plane, in an airport, or in a foreign country with no data plan and expensive roaming — which is to say, precisely when a network-dependent app doesn't work. The record has to be fully readable and writable with no connection, which means the local store is the source of truth and anything else is a convenience layered on top.

Maps are a first-class platform capability. A filling-in world map that pans, zooms, and renders smoothly is exactly the kind of thing the platform's own mapping stack does well and a web canvas does adequately at best. On a product where the map is the payoff screen, "adequate" is the wrong target.

It's a decades-long personal archive. This is data someone expects to still have in twenty years. That argues for it living on the user's own device, in a durable local store, backed up through the platform's own mechanisms, and exportable — not held hostage in a service that has to keep existing for the record to survive. Local-first isn't a technical preference here; it's a promise about who owns the data.

Add the small things a native build gets almost free — a widget-sized glance at your count, sensible sharing of the map image, native date and location handling — and the case is clear enough that the reverse would have needed defending.

What it taught me

Two things carried out of this build.

The first is that consumer apps built on a clean data model age far better than ones built on screens. Every feature request Wanderlist could plausibly get — a new statistic, a filter, a year-in-review, an export — is a query against the same entities, not a schema change. Time spent getting the model right up front is the cheapest time in the project.

The second is that in a personal-archive product, the entry experience is the product. Nobody keeps a record that's tedious to maintain, and a record that isn't maintained isn't a record. Every second shaved off logging a trip is worth more than another view of data that never got entered.

Wanderlist is on the App Store. If you're building something that has to keep a real, long-lived record of a person's life — travel, health, collections, anything — the modeling questions above are the ones worth arguing about first.