TransitPulse

TransitPulse helps transit teams fix the right buses first by turning maintenance backlog and ridership data into clear, explainable priorities.

Comment

Inspiration

The inspiration for TransitPulse came partly from my experience as a transit rider. I have been in situations where a bus broke down while I was on my way to an important meeting. Moments like that highlight how much riders depend on reliable service.

It made me think about the operational side of transit systems. A single missed preventative maintenance task can cascade into service disruptions that affect many riders. At the same time, transit teams often have access to large volumes of maintenance data, but turning that information into quick operational decisions is difficult.

During the Durham College 2026 Hackathon, I wanted to explore how maintenance analytics could help planners make faster and more confident decisions, while also providing context about where service disruptions might affect riders the most.

What it does

TransitPulse is an analytics dashboard that helps maintenance planners identify which buses require attention and what resources should be prepared next.

The system prioritizes vehicles using an explainable risk score that considers overdue maintenance, distance since service, and proximity to the next service interval. The goal is to make maintenance backlogs easier to interpret so planners can focus on the vehicles that present the highest operational risk.

Ridership demand is included as contextual information that highlights where maintenance issues could have the greatest rider impact.

Key outputs include:

  • A ranked maintenance backlog based on urgency
  • Ridership heatmaps that provide context on rider demand and potential service impact
  • Service-kit preparation pages showing parts requirements
  • Site-level pressure indicators for maintenance planning
  • AI-generated operational summaries that help planners interpret the data quickly

How I built it

TransitPulse was built as a full-stack analytics dashboard.

Frontend

  • Next.js and React
  • Interactive dashboard views
  • Service-kit preparation pages
  • Ridership heatmap visualizations

Backend

  • FastAPI services for:
    • Maintenance data processing
    • Risk scoring
    • Parts forecasting
    • Ridership hotspot analysis used for operational context
    • AI-generated summaries

Data Layer

  • CSV and XLSX ingestion
  • Deterministic scoring and filtering logic

Forecasting

A rules-based parts forecasting system maps buses to service-level requirements (A/B/C/D) and estimates quantities needed by maintenance site.

Insight Layer

Structured operational data is summarized into concise maintenance insights to help planners interpret the system quickly.

Challenges I ran into

Building the entire system solo during the hackathon

Developing TransitPulse alone meant designing the product, implementing the frontend, building the APIs, and structuring the data pipeline within a very limited timeframe. I focused on building a working MVP first before layering additional features such as forecasting and AI summaries.

Data quality and mapping gaps

The maintenance, fleet, and ridership datasets were not always cleanly aligned. Some buses or stops could not be mapped consistently across files. I addressed this with fallback handling, and filtering logic so the system could still produce meaningful insights.

Normalizing different operational metrics

Maintenance urgency involves several signals: days overdue, distance overdue, and proximity to the next service interval. Because these metrics use different units, combining them fairly required designing a normalized scoring formula with transparent weighting.

Balancing detailed evidence with quick decisions

Maintenance planners need both fast prioritization and the ability to inspect the underlying data. Designing the dashboard required balancing summary views with details so users can quickly identify urgent buses while still seeing the context behind the ranking.

Accomplishments I am proud of

  • Building a working end-to-end product during a short hackathon timeframe
  • Designing an explainable risk scoring model
  • Creating outputs that are directly actionable for maintenance planners, such as ranked backlogs and parts preparation estimates
  • Developing the entire system solo, including product design, backend services, analytics logic, and UI

What I learned

  • Explainability is as important as prediction when building operations tools.
  • Data integration across multiple systems (maintenance, ridership, GTFS) is where it becomes complex
  • Deterministic analytics combined with AI summaries can be a good pattern: reliable logic with faster interpretation.

What's next for TransitPulse

Future improvements could include:

  • Integrating live GTFS and telemetry data to monitor fleet health in real time
  • Improving the parts forecasting model using historical maintenance patterns
  • Developing automated alerts when maintenance risk exceeds operational thresholds

Built With

Share this project:

Updates