duoyj · Case StudyLiveBus: a map-first TTC tracker for Toronto.
LiveBus puts TTC buses and streetcars, nearby stops, arrival predictions, and route context on one map. When an ETA says five minutes, riders can see whether the vehicle is actually close.
Independent project by duoyj. Not affiliated with or endorsed by the Toronto Transit Commission.
Jan 2026
Public launch after an independent build.
~3,000
First-day visits after launch.
296k+
Views on the Reddit r/toronto post, plus 1,400 upvotes.
~80
Steady daily visits six months after launch, with no ongoing promotion.
A public tool for one specific transit doubt.
- Type
- Real-time transit web map / mobile-friendly PWA
- Location
- Toronto, Ontario
- Role
- Product concept, competitor research, UX direction, spatial interface design, full-stack build, launch, and maintenance
- Core use case
- Answer "Where is the bus?" and "How long until it gets here?" without opening a full trip planner.
- Stack
- Next.js, React Leaflet, Leaflet MarkerCluster, Protomaps PMTiles, GTFS / GTFS-RT data, Umo IQ ETA feed, Cloudflare deployment
- Status
- Live and maintained at livebus.ca
The hard part was not showing arrival time. It was earning trust.
ETAs are useful, but riders still need to know whether a predicted bus is actually close. LiveBus was built around that moment of doubt.
Problem
Toronto riders know the ghost-bus problem: an arrival looks close, but the vehicle is delayed, short-turned, or nowhere near where the ETA implies.
Existing tools are useful, but many start by asking for a route, separate vehicle and stop information, or feel crowded on a phone when someone is standing outside making a quick decision.
The rider's real question: "Can I trust this ETA enough to keep waiting here?"
Solution
LiveBus opens with the map first. Riders can see nearby buses and streetcars, zoom into stops, and compare predicted arrivals with vehicle positions.
The scope stays narrow on purpose. LiveBus is not a trip planner; it is a fast visual check for people already making a transit decision.
The interface stays centered on two questions: "Where is the bus?" and "How long until it gets here?"
Small choices made the tool feel useful quickly.
LiveBus became stronger by not chasing every transit feature. The main decision was choosing what a rider should see first during a quick map check.
Map-first, not route-first
LiveBus opens on the whole city so riders can orient themselves before choosing anything.
Vehicle + stop ETA together
Vehicle markers and stop ETA popups sit on the same map, so a rider can compare a prediction with actual movement.
Browser-first PWA
There is no app-store step. The app opens from a URL and can still be saved to a phone home screen.
Progressive detail
Stops appear only once the map is close enough for them to help, keeping the city view readable.
Route context on demand
Opening a vehicle can show its route shape and detour context, while the extra detail stays out of the way until it is needed.
Lightweight visual language
Clustered vehicle counts, simple layer toggles, and quick map interactions do more work here than decorative UI.
The data existed. The usable view did not.
Before building, I reviewed real-time transit tools including the TTC official map, Transit, Transit Now, My TTC, TTC Watch, and totransit. I compared them around four practical questions:
- Can riders see live vehicle location and direction?
- How quickly can a rider open stop arrival predictions?
- Can multiple routes make sense in one view?
- Does the interaction still work on a phone in a hurry?
The gap was not access to transit data. It was a clearer way to put vehicle movement and arrival predictions together without sending a rider through a full planning workflow.
Real-time feeds, map rendering, and the operational work behind them.
LiveBus is a public web app, not a static demo. The build had to keep changing transit feeds readable, fast, and careful with upstream services.
System outline
Implementation details that matter
- 10-second caching and refresh: vehicle positions and stop arrivals update often, while duplicate upstream requests are kept down.
- Marker clustering: clustered counts keep the citywide vehicle layer readable before the rider zooms in.
- Zoom-aware stops: stops stay hidden until the map is close enough for individual stop choices to matter.
- Route-shape matching: opening a vehicle can fetch a route shape and pick the direction-aware path closest to that vehicle.
- Detour awareness: detour data is polled and surfaced in route and arrival context when it matters.
- Location handling: the app starts with faster low-accuracy geolocation, then refines when high accuracy is available and stays inside Toronto-area bounds.
- Maintenance response: when a vehicle data source broke, the changelog captured the investigation, fallback review, and source migration.
Local riders responded to a focused utility.
After launching LiveBus on January 11, 2026, I shared it on Rednote and Reddit's r/toronto. The early traffic showed that actual TTC riders understood the use case.
For this kind of project, validation is not monetization. It is whether people recognize the problem, try the tool, discuss it, and come back after launch-day attention fades.
~3,000
visits in the first 24 hours
296k+
Reddit post views
1,400
Reddit upvotes
~500/day
visits one week after launch-period promotion cooled down
Why LiveBus belongs in the portfolio.
LiveBus is a small public utility, but it shows several larger capabilities at once: product judgment, spatial UX, real-time data work, and shipping something real people can use.
Starting with a real rider annoyance
The project starts from a real rider question, not a generic map-app premise.
Turning public data into a usable product
GTFS, vehicle feeds, ETAs, stops, shapes, and detours come together in one practical interface.
Designing spatial UX
Map scale, clustering, layers, and route context keep a busy live feed readable.
Shipping a live public web app
The app is deployed, indexed, mobile-friendly, and usable by the public.
Using AI assistance without losing product judgment
AI-assisted workflows helped move from idea to working product while the product choices stayed deliberate.
Learning from real users
Real launch traffic and Reddit discussion gave the project feedback beyond private testing.
Keep the product narrow enough to remain useful.
LiveBus works because it does not try to answer every transit question. It focuses on a common, high-frequency doubt and makes that doubt visible on the map.
Next improvements should add feedback and reliability context without burying the fast check that makes the app useful.
- 1Lightweight feedback: let riders flag bad data, broken stops, confusing route displays, or missing context without writing a long message.
- 2Reliability notes: describe known feed limits in plain language, especially when vehicle positions and ETAs disagree.
- 3Selective route tools: add filtering or favorites only if they help repeat riders without turning LiveBus into another trip planner.
- 4Accessibility and mobile polish: keep improving tap targets, popup readability, contrast, and small-screen behavior.
- 5Case-study reuse: use the same pattern for other public-data map tools: real-time feed, map-first UX, local need.
Interested in maps or public-data tools?
I am open to selected collaborations on spatial web apps, civic tools and maps, local information products, and lightweight data-driven prototypes.