Why every itinerary app breaks when you're a nomad

If you travel for a living, you’ve probably tried the popular itinerary apps and quietly given up on all of them. Not because any one of them is bad, but because they all seem to fight you in the same way. You add a trip, then another, then a third, and somewhere around the second country you stop trusting the thing and go back to a spreadsheet.

It isn’t you, and it isn’t quite any single app. It’s an assumption baked into almost every travel tool ever built: a trip is a discrete thing, with a start, an end, and one destination.

That assumption is invisible right up until your travel stops obeying it. For a two-week holiday it’s correct and helpful. For a rolling, multi-country life it’s the reason the app feels like a chore. This post is about why that happens, why “just make more trips” doesn’t save it, and what a tool has to do differently to keep up with the way nomads actually move.

The hidden assumption: one trip, one destination

Open almost any itinerary app and the first thing it asks you to do is create a trip. A trip has a name (“Lisbon”), a date range, and a place. Inside it you drop your flights and your hotel. When you come home, the trip is over and gets tucked into a “past trips” list.

This is a faithful model of how most people travel: you leave home, you go somewhere, you come back. The container has clear edges because the journey has clear edges.

A nomad’s travel has no such edges. You don’t leave from home and return to it, because “home” is wherever you currently are. You don’t take a trip; you’re on a continuous route that bends through cities and countries with no obvious seams. The flight that ends one stay is the same flight that begins the next. There’s no point where everything stops and resets.

So when an app insists on a trip container, you have to invent the seams yourself. And the seams are exactly where things break.

The four ways the trip container breaks

1. A multi-country route doesn’t have natural trip boundaries

Say your next few months look like this: fly to Lisbon for three weeks, train to Madrid for two, fly to Marrakech for a month, then fly out. That’s one continuous journey. But the app wants trips, so you have to chop it up.

Do you make one giant “Europe + Morocco” trip with everything inside it? Then the trip view is a wall of bookings spanning two months and three countries, and the “where am I and what’s next” question, the only question you actually open the app to answer, gets buried.

Or do you make three trips, one per city? Then you’ve split a single route into pieces that don’t know about each other, and you hit problem two.

2. The legs between destinations belong to nowhere

Here’s the part that quietly drives people to spreadsheets. If you make a trip per city (“Lisbon,” “Madrid,” “Marrakech”), where does the train from Lisbon to Madrid go?

It’s the last thing of the Lisbon trip and the first thing of the Madrid trip at the same time. It belongs to both and neither. You end up duplicating it into both trips, or dropping it into one and forgetting which, or leaving it out entirely and hoping you remember it’s there. The connective tissue of a nomad’s route is precisely what the container model has no good home for: the trains, the budget flights, the transfers between stays.

3. Trips overlap, and containers don’t

Real nomad logistics don’t queue up neatly. You book next month’s flight while you’re still settling into this month’s apartment. A friend’s wedding back home lands in the middle of a stay you’ve already booked around. A visa run interrupts a longer stay and then you come back to the same place.

Discrete trip containers assume one trip finishes before the next begins. When they overlap (and for frequent travelers they constantly overlap), you’re forced to decide which container a booking “really” belongs to, for bookings that genuinely belong to two things at once.

4. You become the integration layer

Add these up and the result is that you are doing the job the software was supposed to do. You’re the one deciding where each booking lives, copying the in-between legs, reconciling the overlaps, remembering which trip is the current one. The app stores your bookings, but the structure (the actual itinerary) lives in your head.

That’s the work. And it’s why so many people who travel seriously end up back in a spreadsheet.

The spreadsheet is the most-recommended “itinerary app” in nomad communities for a reason. It’s the only tool flexible enough to model a route that doesn’t fit anyone’s trip container. It just makes you do all the work, forever, by hand. Every booking is a copy-paste job, every change is a manual edit, and nothing in it is ever live.

Why “just make more trips” doesn’t fix it

The obvious reaction is to say the user is holding it wrong: break the route into more, smaller trips, and discipline yourself to file things correctly.

But that’s treating the symptom. The more trips you create, the more seams you have to invent, the more in-between legs end up orphaned, and the more overlaps you have to adjudicate. You’re not removing the work; you’re multiplying it. Smaller containers are still containers, and a continuous route still doesn’t have the boundaries they demand.

The problem isn’t the number of containers. It’s the container itself.

The fix: stop containerizing, start sequencing

The way out is almost embarrassingly simple. Don’t group bookings into trips at all. Put every booking on one continuous timeline, in the order things actually happen.

A flight to Lisbon, three weeks of an apartment, a train to Madrid, two weeks of a coliving, a flight to Marrakech, a month in a riad, a flight out. That’s not three trips. It’s a sequence. Lay it on a single line in chronological order and every one of the four problems above simply doesn’t arise:

• There are no trip boundaries to invent, because there’s no container.
• The in-between legs aren’t orphaned, because the train from Lisbon to Madrid is just the booking that comes after the Lisbon apartment and before the Madrid coliving. It has an obvious place: between them.
• Overlaps stop being a contradiction. Next month’s flight, booked today, just sits at its correct point on the line.
• You stop being the integration layer, because the order is the structure, and the tool maintains it.

This is the model Skaoot is built on. There’s no “create a trip” step. You forward a booking confirmation, and it lands on a single timeline in the order it happens, however many countries that timeline crosses. See how the unified timeline comes together.

A fair note on what’s covered today: Skaoot fully supports flights and stays right now, with trains, rentals, visas and more on the way. Forward one of those other bookings and the email is saved to your Skaoot inbox, ready for the moment that booking type ships. The timeline model, though, is the part that matters for this discussion, and it was designed for rolling routes from the start.

When the trip container is actually the right tool

Honesty matters here, because the container model isn’t wrong. It’s just narrow. If you take one or two clearly-bounded holidays a year, a trip-based app is a genuinely good fit. The container matches the journey: you leave, you go to one place, you come back, the trip ends. There are no in-between legs to orphan and no overlaps to reconcile, so none of the breakage above ever shows up.

If that’s your travel, you don’t need a different data model, and you certainly don’t need to read a 2,000-word post about one. TripIt and tools like it will serve you well, and they’re cheaper.

The container only becomes a cage when your travel becomes continuous. The test is simple: does your next “trip” have an obvious end, or does it just roll into the one after it? If it rolls, you’re going to spend your life fighting containers, and a timeline will feel like someone finally removed a weight you’d stopped noticing.

What to look for in a tool, if you travel this way

If you’re shopping for something that won’t break on a nomadic route, the data model is the first thing to check, ahead of flight tracking, notifications, or price. Ask:

• Does it force me to create a trip? If the first action is “name your trip and pick dates,” it’s a container model. Find out how it behaves across countries and overlapping dates before you commit.
• Where do connecting legs live? Trains, ferries, and transfers between stays are the canary. If there’s no clean home for “the thing between two cities,” you’ll be the one filing it.
• What happens when plans change mid-route? A continuous timeline updates in place. A container model often spawns a duplicate, which is a whole separate headache. (We wrote about that one in your travel itinerary is lying to you.)
• Can I see “what’s next” in two seconds? That’s the real job. If answering it means scrolling through trip containers to find the active one, the structure is working against you.

The bottom line

Every itinerary app that breaks for nomads breaks for the same reason: it models a trip as a box with edges, and your travel doesn’t have edges. You can keep inventing seams, orphaning your connecting legs, and reconciling overlaps by hand, or you can drop the box entirely and put everything on one line in the order it happens.

If your travel is occasional and bounded, the box is fine; keep it. If your travel rolls (one country into the next, plans booked on top of plans, no clean reset between), a continuous timeline isn’t a nicer version of the same thing. It’s the thing the container was always a poor imitation of.