Inspiration

Flyeasy started from a personal frustration with flying solo. On a long-haul flight you're sitting inches from a hundred strangers for ten hours and never say a word - and that disconnect is weirdly worse on the long flights, where there's actually time to have a conversation. I'd land in a new country having spent the whole flight in my own head, wondering whether the person two rows ahead was going to the same conference, the same neighborhood, the same anything.

The premise of Flyeasy is simple: people on the same flight have already passed the same opt-in. They're going to the same place at the same time. That should be the easiest social primitive in travel, and it doesn't really exist as a product.

What it does

  • Sign up with email, then save your flight by entering a flight number + date - Flyeasy verifies it against a real flight-schedule API and stores the route, times, terminals, and aircraft.
  • See who else has saved the same flight and send a connect request. Connections are mutual - a request has to be accepted before a conversation can start, and either person can pause a chat afterwards without losing the history. One switch in your profile takes you out of every list, keeping existing connections intact.
  • Tap any saved flight to get LLM-powered "Things to do" suggestions for the origin or destination terminal (restaurants, lounges, sleeping pods, attractions) generated by Claude with awareness of your specific terminal and how much time you have until the flight.

How i built it

The app is a single React Native + Expo (SDK 54) codebase in TypeScript, with file-based routing via expo-router. Every UI primitive is built on a custom token-based design system with two independent theming axes (accent palette + background palette) that swap live.

The backend is Supabase — Postgres for data, Supabase Auth for sign-up/sign-in (with email confirmation), and Row-Level Security policies on every user-scoped table so the client never has to filter by user manually. Sessions persist via AsyncStorage so users stay signed in across restarts.

Flight verification uses the AeroDataBox API (via RapidAPI). The 3-step add-flight wizard hits GET /flights/number/{n}/{d}, normalizes the response, lets the user pick if there are multiple matches (overnight flights, codeshares), and INSERTs into Supabase scoped to the signed-in user.

Chat runs on Supabase too — threads, messages, unread counts and pause state all live in Postgres behind RLS. There's no realtime layer yet, so new messages arrive via timer-based polling while the app is foregrounded.

The "Things to do" feature is powered by the Anthropic Claude API (running on claude-haiku-4-5 for cost). The system prompt defines guardrails (no fake hours/prices, name specific venues, prefer the given terminal) and the JSON shape; the user prompt carries the airport, terminal and time-to-flight context. The response is parsed and rendered as cards with category icons.

Challenges I ran into

  • Booking verification is harder than it looks. The original idea was passenger name + booking confirmation number, verified against an airline. Turns out true PNR lookup is gated behind GDS accreditation (like Sabre, Amadeus — contracts and fees) and the consumer-facing booking APIs (Duffel, Amadeus Self-Service) only retrieve orders booked through their own platform. I pivoted to flight-number + date + flight-info enrichment, which is what most lightweight travel apps actually do.
  • Designing the social scenario without it feeling creepy. "Same flight" is the explicit consent signal. No location tracking, no proximity scanning — if you didn't save the flight, you don't appear in it. Beyond that, consent stays mutual all the way through: nobody can message you until you've accepted them, and you can go invisible or pause a conversation without deleting anything.

Accomplishments that I'm proud of

  • A working end-to-end auth + flights flow on a real backend, not stubs — sign up, save a flight, see it persisted with RLS protecting your data, delete it, the whole loop.
  • The terminal-aware LLM suggestions actually feel useful, even though simple and in an early stage at the moment. - Tapping a flight and getting "Plaza Premium Lounge, ~10 min from gate B22" feels like the airport is finally explaining itself.
  • The design system. Every color, font, and spacing value is a token. Adding a new accent palette is a one-line append; the entire UI re-themes live.

What I learned

The real PNR lookup market is closed by accreditation, not by tech. Knowing that early would have saved a week of API research. The useful prompt work was deciding what Claude couldn't say. It'll state opening hours as confidently as it states a venue name — and hours and prices are exactly the things that go stale and turn a suggestion into a wrong one. So I scoped it to what it's reliably good at: which places exist and roughly where they are, with walking times framed as approximate. Narrowing the claims is what made the feature trustworthy enough to ship.

What's next for Flyeasy

Some suggestions are:

  • Real-time chat via Supabase Realtime to replace the current polling, plus push notifications so a message doesn't need the app open to arrive.
  • Layover detection — automatically spot consecutive flights with the same airport in the middle and surface suggestions for the layover (sleep / lounge / leave-the-terminal) bucketed by available time.
  • Push notifications when someone else saves the same flight as you.

Built With

Share this project:

Updates

Submission history