The Making of Switch - Part 1: Motivation

This post is the first in a new series related to Switch, my autonomous train journey tracking app. Even though Switch is far from being a finished product, it’s already mature enough to create some actual value for me. This felt like the right time to set out and explain how this app came to be.

Motivation

Short version: KlimaTicket

Long version: Here in Austria we can buy an annual pass for public transportation that allows us to ride on any bus, tram, train or subway, in the entire country, without ever having to think about ticketing. Just board and go. I’m now on track to finish my third year traveling with the KlimaTicket in my wallet. A lot of times I get asked whether it’s actually cheaper than buying individual tickets, or just peace of mind. And honestly, I could not answer this question because of the lack of data. Since there’s no need to badge in or out, check in or out, there’s no way of knowing how many miles you’ve traveled, other than keeping manual notes.

I take that back; There’s actually a feature offered by the Austrian Railways called SimplyGo which allows individuals to use their App to check in and out when traveling on a train. It offers limited visibility into the trip history, but at least you get rewarded for it by earning Vorzugspunkte. However, the catch is that you need to do it manually, so every time you board a train, you have to remember to check in, and then check out at the end of it.

Seeing my partner struggle with the check-in and check-out process herself, I started wondering if there was a better way to keep track of train travel. This was the moment I thought I could do better, by building a fully autonomous system to track my journeys. Since I do travel quite a lot, and spend hours on hours on trains, I really wanted to know.

The Problem Statement

The first step was to distill the problem down to a simple statement or rather question. A system that is able to help answer the following question:

What train journeys did I take?

The answer to this question would then further help me figure out whether the KlimaTicket is actually financially worth it, or not.

While thinking about a solution to this problem, a popular board game came to mind: It felt like playing Scotland Yard in reverse: instead of using tickets to find a location, I had to use my location and timetable to deduce the train.

Existing Solutions

Of course, there are many ways to keep track of train journeys. Like I already mentioned above, you can do it semi-automatically by using the app provided by the Austrian Railways. Or just use pen and paper, or any kind of note-taking app. But this is not what I had in mind.

Since the KlimaTicket already gives me peace of mind, I wanted to also extend that to the tracking portion of it. Fire and forget. None of the existing tools fit that bill.

What I wanted

To me, a truly good product is one that gets out of my way, and works for me, instead of begging for my constant attention. Smart people call that Backseat Software. Additionally, privacy was a big concern, so was battery life and internet connectivity. To summarize, here are the high level constraints I needed Switch to follow:

UX

• Peace of Mind: No need for manual interactions like check-in or check-out
• Auto-detecting connecting trains: For better organization
• Non-intrusive UI: No sticky notification bar

Technical

• Fully Offline: For times when there’s no WiFi on the train, or no reception due to mountains or tunnels (lots of those in Austria)
• Client-side tracking & matching: Focus on privacy, where my data never leaves the device
• No server-side component: Reduce maintenance burden and complexity
• No real-time tracking: Minimize impact on battery life
• Android only: At least for now, since this is my daily driver
• Universal Schedule: Not limited to Austrian Railways

Preparation & Tech Stack

Since I knew this was going to be a mobile app, I leaned heavily on my existing experience with the React Native platform. This allowed me to get started quickly and test out ideas with fast feedback. And since my primary phone is a Google Pixel, I constrained myself even further and decided to only target Android initially. So, getting off the ground shouldn’t be too tricky I thought, given that we have LLMs at our disposal, and a vast ecosystem of APIs to draw from.

Train Travel Terminology

While architecting the system, I realized the importance of consistent terminology, helping to stay on track. In the transportation world, a lot of terms get used interchangeably, blurring their meaning, making it more difficult to clearly communicate its intention. Here’s a short primer on the terms used in this and the coming chapters:

• Journey: The full path, from origin to final destination. For example when traveling from Wien to Hallstatt, most passengers need to switch trains to reach their destination. This is considered a full journey, even when taking more than one train.
• Leg: A leg is an uninterrupted section, where the passenger stays on the same train. One or more legs make up a journey. For example, when breaking up the above journey, it results in two legs: Wien –> Attnang Puchheim and Attnang Puchheim –> Hallstatt
• Train-Trip: A specific train’s path, from its origin to the final destination, as defined by the timetable. For example being on train RJX 53 means I’m somewhere between Vienna and Villach, between 11am and 3pm.
• Stop: A stop along a train’s path, according to its schedule.
• Station: The actual physical train station building, serving multiple platforms and trains.
• Track: Train movement is limited to the tracks they run on.
• Timetable: The schedule and operating information of train movement across a region

Getting off the ground

With motivation and full of energy, I kicked into high gear and started working on the first prototype. With the help of LLMs and the Expo framework, I got off the ground quickly, being able to collect my first data-points within the first few hours. But experience told me not to read too much into the early wins, because reality always strikes back. And I was right.

With this series of posts I try to provide more insight into my process, the mistakes I made along the way and how I ended up with a working product.

Read on: Part 2: A location-based App