Hitcher

Hitcher connects the 50,000+ daily Caltrain riders based on their trips and interests.

Idea

Over the past couple months, I've frequently commuted on Caltrain from SF to Palo Alto (and back). On my ride, I noticed that there were a ton of people who were working on things that I was interested in: for example, many riders would wear shirts with their company's logo, or have a code editor open. Occasionally, I'd chat with a few of them, but I usually didn't want to interrupt their ride, as some people see it as a time to work. Still, I wanted to facilitate these types of conversations, since they can lead to unexpectedly awesome benefits (e.g., new ideas or friendships); so, I decided to create an app (Hitcher) that would connect people (like a train hitch connects trains) who shared similar interests during their commute.

Functionality

Users sign in with LinkedIn, which populates their profile information, including skills and work/education info. Once signed up, a user selects their Caltrain trips from data pulled from the Caltrain Data Feed. Once a user has entered his/her trips, (s)he can view the other users on those trips and choose to match with those riders; the matching process is double-blind (similar to Tinder) to encourage users to feel comfortable making match requests. Once matched, users can message each other through the app to set up the details of their meet-up (e.g., when to meet-up and where they're sitting on the train).

To make the matching process user-friendly and increase user-engagement, I incorporated push-notifications to alert users when events that are relevant to them occur; users get push-notifications when any of the following occurs:

A new rider joins to one of the user's existing trips

The user matches with another rider (i.e., both users request to meet with each other)

The user receives a message from one of their matches

Technology

I made Hitcher with the MEAN stack, using ObjectRocket as the database provider. I was very excited to work with the MEAN stack, as I had no experience with MongoDB and very little experience with Node+Express. Because I wrote the mobile front-end with Javascript, I found Mongo's document-based DB structure to be a natural fit. ObjectRocket's hosting worked great for me -- it's fast, painless to set up, and appears to provide a daily backup (though I haven't had time to test that yet). Additionally, the document-based structure of Mongo fits really well for the data that I am storing -- for instance, users tend to have a small number of recurring trips, so my DB stores trips as nested properties of users, which allows for quick and easy access/querying. Finally, I used Ionic as a framework on the mobile front-end, and I could not recommend it enough.

Referral Program

I plan on launching Hitcher in the weeks following this competition, so I incorporated a referral program to help grow the user-base. The winning prize is a gift card for a free week of coffee. The referral program is incorporated into the app and will be included on the site (when the app is approved on the App Stores). In the app, users can share their referral code via a QR code or site link. On the website, anyone who visits (regardless of whether they ride Caltrain) can create a referral link to share with Caltrain riders. Referrers then get a referral point (a virtual raffle ticket) whenever the following two events happen:

They refer someone who installs Hitcher

Their referred user matches with another user

Since the reward is not related to the app (and is something most people like), it encourages people to spread the word; additionally, since each referred user can exponentially increase a referrer's chance of winning, people are further incentivized to share.

Future Plans

Because the Caltrain Data is based on an open transit specification GTFS and I built Hitcher around this spec, Hitcher could incorporate new transit systems that provide this spec data (e.g., NY's MTA and Chicago's CTA). If I find that people use this app, then I'd love to add other cities.

Currently, the Hitcher is routine-based: users enter their schedule and find riders based on that pre-populated data. I'm very interested in location-based connections and may extend Hitcher to facilitate this idea, especially with an on-demand component (i.e., no need for users to pre-populate their data to find nearby). If I pursue that functionality, MongoDB would continue to be a good fit with it's support for geospatial data.

Thanks for checking out Hitcher -- please contact me if you have any feedback or suggestions!

-Liam

liampronan@gmail.com