WIMB (where is my bus?)

WHIM is built for the trip you take every day. Pick your route and stop, then just glance: bus 154, ETA 3:44, running 4 minutes ahead. The bus stop arrival screen that actually works, on your phone.

Comment

Inspiration

Every morning, I take the same bus from the same route, from the same stop. The Transit App makes me navigate maps, trip planners, and multiple screens just to answer one question:

Where is my bus? The physical arrival display at my stop is broken and I'm guessing expensive to maintain. Yet the data already exists: Golden Gate Transit publishes both its timetable and a live feed.

WIMB turns that data into the boring, glanceable experience daily commuters actually need without the planning overhead.

What it does

Choose a route, direction, and stop (limited to Route 154 for this POC) and WIMB shows:

  • The next scheduled runs, identified as “Bus 6 of 7”
  • Scheduled arrival time and live vehicle ID
  • A second-accurate arrival estimate
  • The last confirmed stop behind that estimate
  • Realtime-data freshness
  • Honest timetable-only states when tracking is unavailable
  • A clear message when service is finished for the day

The calculation is intentionally transparent:

scheduled arrival + last confirmed deviation − current time

So instead of an unexplained prediction, riders see:

ETA in 6 minutes and 07 seconds as of Terra Linda Bus Pad · updated 14 sec ago

No maps. No trip planner. One glance, one answer.

Try it at wimb.luispe.me.

How we built it

WIMB joins Golden Gate Transit’s static GTFS timetable with the 511 SF Bay GTFS-Realtime feeds.

  • Static GTFS provides schedules, service calendars, stop order, and stable run identity
  • TripUpdates provide schedule deviation
  • VehiclePositions confirm the bus’s progress
  • FastAPI serves the application
  • HTML, CSS, and JavaScript provide the glanceable interface
  • Uvicorn, Caddy, and systemd run it on a DigitalOcean Droplet
  • A short-TTL memory cache limits realtime API traffic
  • A five-minute cron and expiring per-trip checkpoint preserve confirmed progress
  • A separate audit collector records human-readable and JSONL validation evidence

There is no database in this POC.

Challenges we ran into

  • Building and deploying the POC in less than a day
  • Moving from Vercel to a single full-stack DigitalOcean Droplet
  • Discovering that “realtime” data is not always reliable
  • Handling missing and regressing stop sequences
  • Separating completed-stop evidence from future predictions
  • Defining honest behavior when fewer buses are trackable than requested

The key product guideline: don't make it up. When live evidence is missing, WIMB shows the timetable and says tracking is unavailable.

Accomplishments that we’re proud of

  • Shipped a working full-stack product in under a day
  • Created stable “Bus X of Y” identities from the published timetable
  • Built explainable arrival estimates tied to confirmed evidence
  • Handled incomplete realtime data without inventing bus history
  • Added automated tests and production audit capture
  • Deployed something that directly improves my commute (fingers crossed)

What we learned

  • Live data still needs interpretation and validation
  • “Tracking unavailable” is a valid product state
  • Stable bus identity should come from the timetable, not the vehicle number
  • Explainable estimates can be more trustworthy than opaque predictions
  • Small interfaces often require the deepest backend work

What’s next for WIMB?

  • Real user testing + Bug squashing
  • More routes
  • “Last seen at this stop” history
  • Notifications / Subscriptions for early or delayed buses
  • An estimated arrival screen that runs on a screen every rider already owns

Built With

Share this project:

Updates