Flyeasy

Flyeasy turns the loneliest part of solo travel, sitting next to strangers for hours, into the friendliest, by connecting you with verified passengers on your exact same flight.

Comment

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, send connect requests, and chat until the plane lands. After landing the chat goes read-only as a small memento of the trip.
  • 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 we 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.

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.

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.
  • LLM features need typed outputs and defensive parsing to be production-grade. JSON schema constraints are great but bring their own footguns; describing the shape in the prompt + parsing carefully is the boring-but-reliable path.
  • Mobile-first design discipline forces you to write less. Every "Things to do" suggestion has to fit in a card on a 6.1" screen — that constraint made the prompt better.

What's next for Flyeasy

Some suggestions are:

  • 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.
  • Email-forwarding parser — forward your booking email to plans@flyeasy.app and Flyeasy parses out the segments, à la TripIt.
  • Real-time chat via Supabase Realtime to replace the current static chat scaffold.

Built With

Share this project:

Updates