Tideline

Dashboard of the App
Opening Page

Inspiration

Fog cancels the only supply flight to St. Paul Island, Alaska, and there's no way to warn the villagers beforehand. In 2025, a single delayed shipment left the village without food for over a month. This is a matter of probability and logistics - we simply needed a system to give that seat on the plane to those who need it most, and not leave the safety of the village to chance.

What it does

Tideline is a community-maintained cargo manifest for isolated, flight-dependent villages. It uses current weather data at the airstrip (wind speed, density of fog, etc) to determine how likely the village is to receive a flight on any given day, and displays this for the community to track.

Every request for cargo is maintained in a shared manifest list, voted on by the community for priority (medications and fuel over lumber and the like), with any residents able to indicate an urgent request, but requiring a second confirmation before being added to the manifest for the next flight. When a flight is likely to be cancelled due to weather, the manifest is re-sorted to prioritize community-suggested cargo, with explanations for users about what was moved and why.

How we built it

The weather forecast uses publicly available, keyless data sources. The NWS station API for the airstrip is used for wind and visibility, while the Open-Meteo Marine API serves as a fallback in the case of cancellation. The frontend is built of presentational react components and a shared data contract to allow concurrent development for the user interface and the core logic and data-processing elements, including a 'simulate weather change' dev option to allow quick iteration and testing of the resubmission algorithms.

Challenges we ran into

The event's own rules page had conflicting information between sections, including differing statements about team size and deadlines. We also had an initial period of research and design spent investigating various related problems (disaster response logistics, accessibility solutions) before focusing in on the domain of the problem.

The most difficult design challenge was defining the algorithm for request prioritization, and designing it in such a way that the logic behind changes to the manifest couldn't be 'gamed' by residents, while still allowing the community to vote on urgent requests and sort the list by priority when a flight was cancelled.

What we learned

The most useful aspect of the event was the iterative design process that allowed us to narrow the scope of our project. Several preliminary concepts were explored before settling on a domain-specific solution to a particular village's circumstances, which made later development faster and more focused.

What's next for Tideline

Fog, limited supply seats on commercial flights, and similar logistics challenges are a problem for many remote, flight-dependent communities. Tideline is designed to be easily adapted to other remote locations with similar access issues and an isolated internet environment; the next logical steps involve building in offline compatibility, an SMS fallback for users without smartphones, and replacing the mock manifest system with a live API from an airline partner.