This is a submission for the MLH x DEV Writing Challenge
What I Built
The fireworks weren't a surprise. So why was the traffic?
The idea for transPEAKtation started with a problem all four of us had experienced before: thousands of people trying to go home at the exact same time.
After a major event, navigation apps are great at telling us that traffic already exists. But by then, everyone has already opened the same apps, received similar route recommendations, and started moving at once.
We wanted to look one step ahead.
transPEAKtation is an event-aware routing platform that predicts where congestion is likely to form before it happens and distributes drivers across routes more intelligently.
Instead of asking:
"What's the fastest route for me right now?"
we wanted to ask:
"How can everyone get from A → B faster?"
That distinction became the core of our project.
How it works
We built a pipeline that combines upcoming events, road incidents, street closures, traffic conditions, and historical time-series data.
Our ingestion system continuously collects and normalizes transportation data from sources including DataSF, Caltrans, and CHP. Events and road incidents are geocoded, deduplicated, and connected to the surrounding road network.
When a user searches for a trip, transPEAKtation considers not only current conditions, but also where and when people are expected to move.
For example, a road beside an arena may look completely normal at 5:00 PM. But if a 20,000-person concert ends there at 10:00 PM, that road probably won't stay normal for long.
Our interface lets users:
- choose Leave at or Arrive by times
- see upcoming events around their route
- view road incidents and closures
- visualize predicted congestion on the map
- compare alternative routes based on future conditions
- understand why a route is being recommended
Rather than optimizing every traveler independently, the long-term idea is to distribute demand across multiple viable routes so that one "optimal" route doesn't become everyone's route — and immediately stop being optimal.
Building it
Our system ended up spanning several pieces:
Ingestion → Storage → Prediction → Routing → Visualization
The ingestion layer collects and cleans live transportation and event data.
We store normalized entities separately from high-frequency, time-dependent observations so each part of the system can be queried efficiently.
Our backend combines this information with routing data, evaluates the conditions surrounding possible routes, and returns context to our web application.
Finally, the frontend turns all of that into something understandable: event markers, road conditions, predicted congestion, route alternatives, and explanations.
One of the things we cared about most was avoiding a black-box experience. If transPEAKtation changes your route because thousands of people are expected to leave an event nearby, you should be able to see that event and understand the recommendation.
And we're still building.
We're exploring how event organizers could publish events directly to the map, how community-submitted information could improve coverage, and how coordinated routing could evolve from simply predicting congestion to actually helping prevent it.
Demo
🌐 Live Site:
https://yowaymo.us
🎥 Demo:
Watch transPEAKtation in action
💻 GitHub:
github.com/No-Way-Mo/transpeaktation
One of our favorite demo scenarios is a trip across San Francisco around a large event.
Instead of treating the route as if the city will look the same several hours from now, transPEAKtation surfaces nearby events, their timing, road conditions, and the congestion they may create.
The result is a route that understands that time changes the map.
Partner Technologies
Two technologies became particularly important to our system during ShellHacks: Tiger Data and AWS.
Tiger Data
Traffic is fundamentally a time-series problem.
A road being congested isn't meaningful without knowing when it was congested. The same street can behave completely differently at 8 AM, 2 PM, or immediately after a stadium empties.
That made Tiger Data a natural fit for transPEAKtation.
We used it for our time-dependent transportation data so we could associate observations with timestamps and efficiently retrieve the conditions relevant to a user's selected travel window.
Our pipeline processes transportation data from multiple sources and stores timestamped observations that can later be compared against event schedules and route segments.
This helped us structure queries around questions such as:
- What conditions were observed on this road?
- How do those conditions change over time?
- What observations fall within the travel window we're evaluating?
- How does the surrounding road network behave around an event?
Separating these time-series observations from our more static event/entity data also made the architecture much cleaner.
Instead of treating traffic as one constantly overwritten value, we could treat it as what it actually is: a signal evolving through time.
That approach eventually earned our team Best Use of Tiger Data at ShellHacks.
AWS
AWS gave us the infrastructure needed to connect the different parts of transPEAKtation into a system that could actually run beyond our laptops.
Our project isn't a single application. We have data ingestion workers, backend services, databases, routing logic, external data sources, and a web client that all need to communicate reliably.
During the hackathon, we used AWS infrastructure as part of deploying and operating those services so our application could process data and serve results to the frontend without relying entirely on a local development environment.
What we appreciated most during the hackathon was being able to move from:
"This works on my machine."
to:
"Our teammates and judges can actually use it."
That infrastructure became an important part of making transPEAKtation feel like a real system instead of a collection of scripts.
We were incredibly excited to receive 2nd Place for Best Use of AWS.
Hackathon Experience
We built transPEAKtation at ShellHacks 2026 at Florida International University.
Our team — Lan Anh Do, Dat Le, Huy Hoang, and me — consisted of four Vietnamese international students with different technical strengths but one unfortunately universal area of expertise:
being stuck in traffic.
For roughly a weekend, our lives became some combination of API documentation, map layers, broken endpoints, database connections, routing experiments, questionable amounts of caffeine, and someone asking:
"Wait... why is that timestamp in UTC?"
We divided the system across ingestion, backend, prediction, and frontend work, but one of my favorite parts of the weekend was how interconnected everything became.
A frontend feature would expose something missing from the API.
The API would reveal a problem with the data model.
The data model would reveal something weird in the source data.
And suddenly all four of us would be staring at the same problem.
We also learned very quickly that building with real city data is messy.
Dates aren't always formatted consistently. Events span multiple days. Roads have different identifiers across datasets. APIs fail. Locations need to be geocoded. Duplicate records appear. And a feature that sounds like "just put the events on the map" can quietly turn into an entire data pipeline.
But that was also what made the project fun.
By the end of ShellHacks, transPEAKtation had gone from a question on a whiteboard to a working system processing thousands of real transportation records and using them to add future context to routes across San Francisco.
And somehow, after all of the debugging, pitching, laughing, and very limited sleeping, we walked away with:
🏆 Best Use of Tiger Data
🥈 2nd Place — Best Use of AWS
The awards were amazing, but the part I'll probably remember most is the team.
Hackathons are one of the few places where four people can spend an entire weekend building something that absolutely did not exist on Friday, watch it slowly become real, break it approximately 47 times, and still leave Sunday already talking about what we want to build next.
We're definitely not finished with transPEAKtation.
Because the bigger question is still interesting to us:
What if navigation stopped optimizing for one driver at a time — and started optimizing how an entire city moves?
Top comments (0)