Conductor is an iPhone app for UK rail built to do one thing better than anything else on the market: tell you your train is running late before the board does. I built all of it — the app, the backend, and the live data pipeline underneath it. It is with App Store review now.
What I walked into
A train that is going to be late usually gives itself away well before the departure board changes. The signals are out there in the live rail data, but by the time the board flips from On Time, everyone standing on the platform has already worked it out for themselves. Nobody had done for trains what Flighty does for flights.
Everything else in the category is a timetable with a nicer interface. I wanted an app that watches the network on your behalf and tells you early enough to do something about it — take the earlier connection, leave the office, stop running.
How the work changed
The only way to be first is to be reading the live feeds yourself, so most of the work is a backend that runs continuously whether or not anyone has the app open. It ingests live National Rail data around the clock and keeps a record of what actually happened on every service, which is the only thing a prediction can honestly be measured against later.
The app on top is the part people see: journey search, live tracking, route maps drawn on real track geometry rather than straight lines between stations, offline journeys, ticket import, sharing, a Live Activity on the lock screen, and a passport of trips you have taken. Search was the first thing that had to get fixed — it started out taking up to fifteen seconds, and rebuilding how journeys are queried brought it down to around three.
The turning point
“The prediction engine has a bar to clear before it ships: it has to beat simply carrying forward the delay a train already has. Until it does that reliably, it stays off, and v1 goes out as live tracking done properly. Shipping a prediction people cannot trust would spend the exact credibility the feature depends on.”
Decisions that mattered
I could have wrapped a public API and shipped sooner. Instead the pipeline has been running continuously for months, building a record that only becomes useful with age. A delay model has nothing to learn from and nothing to be graded against without it.
Live, scheduled and predicted all look identical on a screen unless you force them apart. Each time and platform carries its source and a confidence score, and the app says nothing rather than inventing a state it cannot verify. No answer beats a confident wrong one.
v1 is live tracking. The prediction engine stays off until it earns its place, and the site says so plainly. That order costs me the headline feature at launch and keeps the thing the headline feature actually runs on: people believing what the app tells them.
What exists now
Conductor is submitted and in App Store review, running on live National Rail data across the network: search, tracking, route maps, offline journeys, ticket import, sharing, Live Activities, and journey finalisation that records what actually happened after the trip.
What I am working on now is the part that made me build it in the first place. Connection risk is moving from a station-wide average to a number specific to the train you are actually waiting on, and the next feature after that warns you when the train your service is formed of is already running late somewhere else on the network — the earliest honest signal there is, and one no UK consumer app uses today.
In review
App Store status
Submitted and running on live National Rail data across the network.
~3 sec
journey search, down from 15
Rebuilding how journeys are queried took search from unusable to fast enough to trust.
24/7
live data collection
The pipeline runs continuously, so any prediction can be graded against what actually happened.
What I carry forward
The product promise sounds like a design question and is really a data question. You cannot tell someone their train is late before the official source does unless you are reading the same feeds it reads, continuously, and have been for long enough to know what normal looks like.
It is easy to put a number on a screen and much harder to prove it deserves to be there. Holding the prediction engine back until it beats a simple baseline was the least fun decision on this project and the one I would defend hardest.
The distance between something that works on my machine and something safe to hand to strangers turned out to be most of a week. Review, release hygiene and the boring parts of shipping are a skill, not an afterthought.