Why I built Campus2Air

Getting to and from the airport as a college student is a pain. You either fork out for an Uber, beg a friend, or spend two hours on a bus with two connections. At UC Riverside, where the nearest major airport is a solid drive away, this felt like a problem worth solving.

That's where Campus2Air started — a simple idea: what if students going to the same airport around the same time could just share a ride?

The problem with "just match students"

The naive version of this is easy. You collect departure times, airports, and dorm locations, then pair people up. But in practice it falls apart fast. Someone's flight is at 6am and they need to leave at 4am. Another person is flying out of a different terminal. A third person has a ton of luggage and needs specific seating. Schedules don't line up exactly, preferences vary, and nobody wants to share a car with a stranger they know nothing about.

A simple form-and-match system wasn't going to cut it. I needed something smarter.

Bringing in an LLM

The breakthrough was using a language model to handle the matching. Instead of rigid rule-based pairing, I fed the LLM each student's schedule, pickup location, destination airport, and preferences — and had it reason through the best pairings. It could weigh tradeoffs, account for edge cases, and produce matches that actually made sense for real people.

This turned out to be the right call. The matches were significantly better than anything a simple algorithm would have produced, and the system handled the messiness of real travel schedules gracefully.

Building it end-to-end, alone

Campus2Air is a full-stack application — frontend, backend, database, hosting, legal documentation, and everything in between. I built and deployed the whole thing as a sole founder. That meant making decisions I'd never had to make before: what infrastructure to use, how to handle user data responsibly, what the legal baseline was for running a service on a university campus.

Some of those decisions were easy. Others took research I didn't expect to be doing. But going through all of it gave me a much clearer picture of what it actually takes to ship something real — not just code, but a product.

What I'd do differently

If I were starting over, I'd talk to more students earlier. I spent a lot of time building before validating that people would actually use it. The core idea was solid, but some of the features I built first weren't the ones users cared most about. Getting feedback earlier would have helped me prioritize better.

I'd also think more carefully about the onboarding flow from day one. Getting someone to trust a new app enough to share a car with a stranger requires more than just a clean UI — it requires clear communication about how matching works and why it's safe.

Where it stands now

Campus2Air has an active user base and is live at campus2air.vercel.app. It's one of the projects I'm most proud of — not because the code is particularly clever, but because it's a real thing that real people use to solve a real problem.

That's the bar I want to hold all my work to.