This started the way most college startups do: with a problem I had personally. Getting around as a Berkeley student without a car is annoying but solvable. Getting a ride that isn't a silent, slightly awkward Uber with a stranger is a harder problem.
So I built a ride-hailing platform for college students under Shuffle. But the interesting part wasn't the ride-hailing. It was the matchmaking.
The idea
Standard ride-hailing is purely logistical: someone needs to go from A to B, a driver is near A, match. The rider and driver are strangers and will remain strangers. Fine for a ten-minute commute, but college students are a different market. They ride together frequently, share a social context (same campus, similar age, overlapping circles), and are far more likely to stick with a service if they enjoy the experience.
The hypothesis: if you match riders who are likely to get along (shared interests, mutual friends, similar schedules), the ride becomes a social experience rather than a transaction. Social rides mean higher retention.
The matchmaking algorithm
The matching system pulled from the student's university profile (school, major, year), their connected social media accounts (interests, group memberships, mutual friends), and their ride history on the platform (who they'd ridden with, implicit feedback from repeated pairings).
This is a textbook cold-start problem. New user signs up, you know almost nothing about them. Can't do collaborative filtering ("users similar to you liked riding with X") because there's no ride history yet. What you can do is content-based filtering, using the social and academic profile as a proxy for compatibility.
The algorithm worked in stages. New users got matched primarily on content: similarity scores across major, interests, and social graph overlap. As ride history accumulated, the system blended in collaborative signals. If User A and User B both re-rode with User C, they were more likely to be matched with each other.
Not all signals carried equal weight, and this was the interesting part to discover empirically. Sharing a major turned out to be a weaker compatibility signal than sharing specific interest groups or having mutual friends. The weights were learned from implicit feedback: re-rides (choosing to share a car with someone again) were positive signals, one-time rides that never repeated were weak negatives.
What I actually learned
The ML was interesting but honestly secondary to everything else I picked up. How to scope a product. How to talk to users. How to prioritize when everything feels urgent. How to ship something imperfect and iterate on it.
The matchmaking algorithm taught me a lot about recommendation systems and cold-start strategies, knowledge I've carried into every ML project since. But building the startup taught me that the algorithm is maybe 20% of the problem. The other 80% is operations, trust, user acquisition, and not running out of money.
The platform was end-to-end: user registration and profile building, social media integration for interest extraction, the matching pipeline, ride coordination with real-time tracking, payment handling, and a feedback loop that fed back into matching. A lot of moving parts for a college side project. Managing that complexity, knowing which parts to build well and which to build quick, is a skill I use daily.
There's a direct line from this project to the AI agent work I did at 11Sight and later at Amazon. In all three cases, the core challenge is the same: use machine learning to understand enough about a person's context and preferences to take useful actions on their behalf. Whether you're matching riders, booking car appointments, or routing queries to the right knowledge base, you're building systems that need to understand humans. Not in the general AGI sense, but in the practical "what does this person need right now and how do I get it to them" sense.
That's the thread across everything I've worked on. Not "AI" as an abstraction, but AI applied to specific problems where the gap between what people need and what existing systems provide is too wide for either side to close alone.