Layover

Layover: when a flight changes, see what’s at risk, what to do next, and send the update to the people waiting on you.
One flight changes, and the whole trip rebuilds: alert, new plan, checklist, and the message home.
The new plan, worked out for you: the missed connection, the new arrival time, and the hotel and pickup now at risk.
Ready-to-send messages for each person waiting on you, plus a read-only page with the live plan.
How it’s built: pure, tested functions do the thinking. The flight feed is simulated for the demo.
Four people, 24 hours, Into the Skies. Built at hackPHS 2026.

Inspiration

Your flight gets delayed, and suddenly you’re digging through an airline app, confirmation emails, a hotel booking, and a group chat while dragging your luggage around. The info is all there; it’s just everywhere. We wanted one place that tells you what changed, what that puts at risk, and what to do about it.

What it does

Layover turns “my flight changed” into a plan. Your flights, stays, booking references, and contacts sit on one timeline. Tap a reference to copy it, tap a contact to call. When a flight changes (delay, cancellation, missed connection, rebooked), you see old vs. new side by side, plus what’s now at risk, like a 55-minute connection turning into 10 or landing after your hotel’s check-in cutoff. From that, it builds a checklist with tap-to-call buttons and a progress bar. Then it writes the update for whoever’s waiting on you, with booking references hidden by default. Send it from the share sheet, copy it, or share a read-only link. Your trip feeds the checklist,t and both feed the message, so you never type anything twice.

How we built it

Layover is a phone-first web app built with Next.js, TypeScript, and Tailwind, and it’s live on Vercel. Zustand saves your trip on your phone, so there’s no database. Zod checks the data, and Vitest tests the logic. Share links pack the update into the URL itself with lz-string, so nothing goes through a server. Two extras do use a server: importing bookings from pasted text (Anthropic) and the spoken summary (ElevenLabs). All four of us built at the same time, and each person owned their own files. A shared CLAUDE.md kept everyone’s Claude Code sessions on the same page.

Challenges we ran into

Four people in one repo for 24 hours is a recipe for merge conflicts. So we split up the files and locked in our data types and function names before anyone built a screen. Time zones almost got us. We just store local clock times and only compare times in the same city, so we never have to convert anything. Sharing without a database meant cramming the whole update into the link. Late Saturday, our testing found that bad saved data could leave the app stuck on “Loading your trip” forever, so we fixed that. And we had to be real about what we could finish. There’s no live flight feed, so the demo fires a scripted airline change, and “Handled for you” (telling the hotel, moving the pickup) is faked. Import works from pasted text, not your inbox.

Accomplishments that we’re proud of

The whole thing works on a phone. The trip is on track, the airline changes a flight, the plan rebuilds, and the update goes out to whoever’s waiting. We ran the demo three times in a row on the live site,e and it worked every time. 241 tests pass, including the ones behind the warnings, so when it says your connection just dropped to 10 minutes, that’s tested code. Shared updates live entirely in the link, so there’s no account and no server. We also added a Solana “Send help” button so the person waiting can chip in on costs. It’s on devnet, so no real money moves.

What we learned

Agreeing on data types and function names first saved us the most time. Keeping the logic in plain functions made it easy to test without opening a browser. A shared CLAUDE.md kept all four of our Claude Code sessions building the same app. And it’s way better to say what’s faked up front than hope nobody asks.

What’s next for Layover

Hook up a real flight-status feed, so changes come from the airline. Import bookings straight from confirmation emails. Test it on a real phone with real travelers, since so far we’ve only tried it at phone size in a browser. Then optional sync across devices, with local-only staying the default.