Building World Travel Tracker: An Android App Case Study

World Travel Tracker started from a simple, personal itch: wanting a visual record of which countries I'd actually been to, without relying on a spreadsheet or memory.

The core idea

A map-based interface where visited countries get marked directly, with the data structured well enough to export and use elsewhere — not locked into the app.

Why a map, not a list

A list of country names is functionally complete but doesn't give the same at-a-glance sense of coverage a visual map does — seeing which regions are unvisited is immediately obvious on a map in a way a text list doesn't convey. This was the actual reason to build a dedicated app instead of just using a spreadsheet or note.

Offline-first by necessity, not preference

Travel is precisely the situation where connectivity is least reliable — the app needed to work fully without a connection, since checking off a visited country in a remote area with no signal is a completely normal use case, not an edge case. This meant designing the data layer around local storage as the source of truth from the start (see our offline-first architecture guide for the general pattern this follows) rather than retrofitting it later.

Why JSON export

The data model is simple — a list of visited countries with metadata — which makes JSON a natural fit: human-readable, easy to back up manually, and easy to bring into other tools or scripts if someone wanted to do more with their own data than the app's built-in views provide. A proprietary binary format would have solved nothing the app itself needed and would have made the user's own data harder for them to access outside the app.

{
  "visitedCountries": [
    { "code": "IT", "name": "Italy", "visitedDate": "2024-06-12" },
    { "code": "DE", "name": "Germany", "visitedDate": "2023-11-03" }
  ]
}

What I'd emphasize for anyone building something similar

• Start with the data model, not the map UI. The map is a rendering of the data — getting the underlying structure (what counts as a "visit," what metadata matters) right first makes the visual layer straightforward afterward, not the reverse.
• Offline-first isn't optional for travel-context apps — it's close to the core requirement, not a nice-to-have.
• Export in an open format if there's any chance users will want their data outside your app — it costs little upfront and avoids a real trust problem later.