36 sessions. 1 app that finally routes home.

The origin

A conversation, discussing potential problems and gaps turned into solution

The idea came out of a conversation with a friend, comparing where Apple Maps and Google Maps each fall short — lane guidance, how traffic renders, small stuff neither one gets fully right — and somewhere in that conversation the question became "why not both."

What I actually chased was narrower than that. Both apps make you commit to a mode before they'll plan anything — driving, or public transport, never mixed — even though a lot of real trips are neither. Drive to a station, train partway, maybe walk the rest. NavMelb started as an attempt to answer that one gap directly: let a route explicitly chain car and PTV legs together instead of forcing an either/or pick. (I later found out Google Maps do some auto-connecting here already, but at least not manually and continued on the project that was primarily my first time building something full-stack with AI as a collaborator.)

Because it was my first time working with AI like this, I made a point of AI-assisted documenting after each session on what worked and what didn't as I went — partly so I wouldn't repeat the same mistake twice, partly so I could actually explain afterward what happened, not just that it eventually worked. This build log is what that habit turned into.

Mar 20 – Mar 29, 2026

Teaching the app what a "stop" actually is

Melbourne's public transport data doesn't agree with itself. The same physical station shows up under different names depending on which data feed you ask — "Clayton Station" in one, "Clayton Rd Station" in another. Worse, a train station is really two different records in the data: a general entry with no trains attached to it, and a separate "platform" entry that's the one trains actually use. Early on, the app kept finding the wrong one, so it looked like routing was broken when really it was just asking about a place that, as far as the timetable was concerned, had no trains.

The fix wasn't cleverer searching — it was building one address book, once, that every part of the app reads from. Every stop gets a clean "filing name" so near-duplicates land in the same drawer, a separate polite name for what the user actually sees, and a hard rule that routing always resolves to the platform that has real trains, never the parent record that just groups platforms together.

Mar 5, 2026 → generalized Mar 29, 2026

One journey can zig-zag between car and train, and that's fine

A real trip across Melbourne is rarely just "drive" or just "get the train" — it's drive to a station, train partway, maybe another train, maybe drive again at the end. The first version of the app tried to handle this with one fixed pattern: car, then train, then car, always in that order. It broke the moment anyone wanted two train legs in a row, or train-car-train.

Instead of one rigid pattern, the app now looks at each consecutive pair of stops on its own. Station-to-station becomes a train leg; anything else becomes a car leg. String together as many stops as you like, in any order — each pair decides its own leg type independently, so new combinations just work without anyone having to add a special case for them.

for (let i = 0; i < allPoints.length - 1; i++) {
  const from = allPoints[i], to = allPoints[i + 1];
  if (from.type === "station" && to.type === "station") { /* PTV leg */ }
  else { /* car leg */ }
}

Formalized through Apr–May 2026

When one leg breaks, the trip doesn't have to

If you plan a four-stop trip and one leg genuinely has no route between it, the old behavior would be to reject the whole request — no map, no information, just an error. That's frustrating when three of the four legs are perfectly fine and could have been shown.

The server now returns every leg it could actually solve, and clearly flags the one it couldn't, instead of throwing the whole trip away over a single broken segment. The map draws what worked and shows a plain-language note on what didn't.

segments: (RouteSegment | FailedLeg)[]
const hasFailures = segments.some(s => s.type === "failed");
res.status(hasFailures ? 207 : 200).json(response);

Mar 24 – Mar 25, 2026

The server that couldn't say hello

Twice, the entire app appeared to be down — every request timed out, even simple ones like searching for a station name. Both times, the actual problem had nothing to do with the network: the server was doing a huge amount of work first — loading millions of timetable rows, or searching a giant nested list of possible train transfers — before it ever got around to accepting a single connection. It's the equivalent of a receptionist who won't pick up the phone until an entire filing cabinet is done.

The fix was splitting "what must happen before we answer the phone" from "what can keep happening quietly in the background." The server now starts accepting requests immediately, and slower background work finishes on its own — with a hard cutoff so no single search can hold up the whole app indefinitely.

await loadGtfsTimetables();
await loadGtfsStops();
app.listen(PORT);              // server starts HERE
loadRaptorStreaming().catch(); // background

Mar 27, 2026

Labeled boxes, instead of guessing what's inside

Some data in the app can be one of two different shapes — a direct trip versus one with a transfer, for instance. The early code stored both in boxes that looked identical from the outside, and just trusted that whoever opened the box already knew which one it was. That trust broke at least once, and needed an unsafe workaround to paper over it.

Every such box now carries its own label built into its type — "this is a direct trip" versus "this is a multi-leg trip." The rest of the code is required, by the compiler, to check the label before it's allowed to assume what's inside.

type TripResult =
  | { kind: "direct";    tripId: string; stops: StopTime[] }
  | { kind: "multi-leg"; legs: DirectTrip[] }

Mar 27, 2026

One ruler, not four that might quietly disagree

Distance between two map points is simple math, but four different parts of the app had each grown their own copy of that calculation independently — and one of the four copies had a small, real bug in it (mixing up latitude and longitude on one line). Whoever hit that one code path got a subtly wrong answer, with no error to flag it.

One shared function now does that calculation everywhere. Fixing or improving it fixes it everywhere at once, instead of relying on someone remembering there are four separate places to check.

// utils/geo.ts — the one copy that survived
export function distanceMeters(coord1, coord2) { /* Haversine */ }

Apr 23 – Apr 25, 2026

Keeping the clock honest across a multi-leg trip

For a trip with three legs, the arrival time of leg one should become the departure time assumed for leg two — otherwise you get three separate, disconnected time guesses instead of one trustworthy "you'll arrive at 5:40pm." A related bug meant the app was also picking the first train it found in the timetable rather than the soonest one — showing a 40-minute wait when the real next train was 8 minutes away. That one took two attempts: the first fix moved the bug to a different loop instead of removing it.

Each leg's calculated arrival time is now threaded forward as the next leg's assumed departure time, so the whole journey tells one coherent time story instead of three unrelated ones.

let currentTime = initialDeparture;
for each [from, to] pair:
  const result = query(from, to, currentTime);
  currentTime = result.arrivalTime;  // thread into next leg

Apr 7, 2026

Quiet in production, loud when something's actually wrong

While building the app, there's a lot of debug chatter that's genuinely useful during development — but noisy, or in the worst case embarrassing, in a live build a stranger might inspect. At the same time, real errors still need to stay visible, because those are exactly what you'd need if something broke for a real user in production.

Ordinary debug logs now switch themselves off automatically outside development. Errors and warnings are deliberately left alone, since incident investigation depends on them.

const log = process.env.NODE_ENV !== "production" ? console.log : () => {};