Anyone who has flown knows how hard it is to find a place to rest on a long layover. For stranded, budget, disabled, or young-family travelers, it's an access problem.
Airports show where gates and restrooms are, not which areas are quiet right now. The alternatives are static reviews or paid pods and lounges, often far from your gate.
People sleep next to their gate for fear of missing their flight. We wanted a free, gate-aware tool so you can rest without that worry.
What it does
TerminallyChill is a no-login web app that forecasts crowd levels inside Atlanta's airport (ATL) and recommends quiet places to rest.
Crowd forecast: Estimates crowd levels per terminal zone from live flight data.
Gate-aware ranking: Enter your gate and boarding time. Spots are ranked by quietness and walk time, with a "leave by" countdown.
No install, no account: It works in any browser, with maps links and an in-app route to the spot.
Zero Data: No external requests, storage, cookies, or analytics in the browser. [If finished: optional photos are counted and deleted immediately, and only an anonymous crowd level is kept.]
Honest limits: Crowd levels are estimates, not guarantees. We launched with ATL and designed the model to extend to other airports.
How we built it
Backend: Python and FastAPI, with a hand-built crowd-flow model over an ATL concourse graph, plus rest-spot ranking, walk times, and the API.
Flight data: A scheduled job pulls ATL flights from FlightAware AeroAPI (one row per physical flight, with aircraft type). Users never hit the flight API.
Database: PostgreSQL on Tiger Data (TimescaleDB), storing crowd estimates as a time series in 5-minute windows.
Frontend: Responsive web UI, tested for mobile.
CV and AI: OpenCV counts people in optional photos in memory. Gemini (text-only) handles natural-language queries.
Deployment: Google Cloud VM with systemd and Caddy HTTPS, live at terminallychill.us.
Testing: 45 passing tests, including against a real Postgres instance.
Challenges we ran into
Flight data is the foundation of the whole app, and it is hard to get reliably and expensive to keep up over time. Providers differ in coverage, licensing, and cost.
The ideal architecture for this kind of service (high availability, distributed) is hard to build well with a small team and limited time.
Accomplishments that we're proud of
We found reliable flight-data sources. This took more time than any other task, and it is the cornerstone of the idea: if the data is unreliable, the app falls apart.
Despite the architectural difficulty, we shipped a working, live MVP in a very short time.
What we learned
Real-world experience matters as much as technical skill. Without lived experience to ground our vision, we couldn't have built something people actually need.
Our stack and architecture were more ambitious than the time allowed, but persistence and commitment to the cause got us through.
What's next for TerminallyChill
We demoed with ATL because it's the airport most of us know firsthand, but the model is built to work with other airports. Each one needs a terminal map and a flight-data feed.
Since the MVP is already live, we can package it as a container that any airport operator can deploy. Operators could plug in their own on-premise flight data, so the service reaches every traveler passing through.
Log in or sign up for Devpost to join the conversation.