Inspiration

Meet Maya, a fictional student heading to a 9 a.m. lab. Her bus is usually fast, but some trips take much longer. A typical travel time does not explain the slow days that can make her late.

Buffer focuses on one decision: which route should she take, and when should she leave? It makes the trade-off between a later departure and more room for slow trips visible. The persona is hypothetical; no user interviews or real-world outcome measurements are claimed.

What it does

Set an arrival time, add an extra buffer, and choose the share of recorded trips to accommodate. Buffer compares route histories and recommends the route with the latest computed departure at that setting. Each route shows its typical duration, travel allowance, departure time and individual trip records.

The bundled examples are explicitly synthetic. With a 09:00 arrival, a five-minute buffer and 90% history coverage, the metro needs a 40-minute allowance and recommends leaving at 08:15. The bus is typically faster but needs 52 minutes to fit the same share of its records. At 80%, the recommendation changes to the bus at 08:19.

Users can select another route, import a local CSV, and copy or download the chosen plan. Imported contents stay in the current tab and disappear on reload. There is no upload endpoint, account or API key.

History coverage is not a future on-time probability or guarantee. The app has no live transit feed or prediction model. Small samples, changing schedules and disruptions limit what the records can tell us.

How we built it

Buffer uses React, TypeScript, Vite, CSS and SVG. For each route, it sorts door-to-door trip durations and selects rank ceil(record count × selected coverage). It subtracts that duration and the extra buffer from the arrival time. The recommendation and underlying dots update together, making the calculation inspectable.

The app was newly created during this hackathon's submission period. Existing frameworks are dependencies, not a reused finished project. The build targets static hosting on GitHub Pages.

AI and presentation credits: The solo participant supplied the project requirements, constraints and release decisions. OpenAI Codex assisted with rule research, idea selection, implementation, design, synthetic examples, tests, documentation and demo preparation. Anthropic Claude coordinated the work and handled publishing steps (repository, deployment, video upload) at the participant's request. The video records actual browser interactions through Playwright; its voice is Windows System.Speech text-to-speech, with captions rendered using FFmpeg. There is no runtime AI model. This statement does not claim that the participant manually wrote the generated implementation.

Challenges we ran into

The main challenge was explaining a historical percentile without presenting it as a forecast. Buffer shows the actual count of records covered and labels the sample data. Ties can cover more records than the selected share, especially with small samples.

Implementation challenges included CSV quoting and validation, keeping the last valid dataset after a bad import, changing route recommendations when coverage changes, preserving the selected route in exports, and explicitly labeling previous-day departures.

Accomplishments that we're proud of

The working prototype covers the complete flow from trip history to a saved departure plan. The production build succeeds. Ten calculation and parser tests and fourteen production browser checks pass, including CSV replacement, invalid inputs, route changes, clipboard, download, midnight and mobile layouts.

These results establish the demonstrated software behavior. They do not establish a measured reduction in lateness or commuting time.

What we learned

A route with a shorter typical trip can require an earlier departure once slower journeys are included. Showing the records makes this reversal easier to inspect than a single opaque score.

Simple calculations still need careful wording and error handling. Counts, provenance and limitations are part of the result, not separate from it.

What's next for Buffer

Test whether students understand the comparison using their own consented logs. Consider grouping by weekday and departure window, showing stale data, and checking whether recent records change a recommendation. Live service information would require a separate integration and validation effort. These are future plans, not current capabilities.