Inspiration
Southeast Asian cities are always packed with motorbikes and scooters. Thousands of people commute to CBDs every day, just to find themselves stranded in traffic jams. Yet, most of them ride by themselves, not carrying any passenger. That is a waste, in terms of room for transportation, fuel cost, and pollution cost. If many of them switch to bike pooling, either being a passenger or taking one, the number of bikes on the roads will be significantly reduced, which then ease the traffic flow, save money and the environment.
What it does
Our app allows bike riders to share their rides, and passengers to book them.
How we built it
At the core of the app is the trip-matching algorithm. When someone posts a trip (either as a rider offering a ride, or a passenger requesting one), we save them to our database. Then when someone else posts another trip that can be matched with the already-saved trip, the compatible trips are shown. An easier case is that the users just go to the app, view the already-posted trips and send direct requests to the trip creators.
At the back-end, we have a server that records all trips to do the matching. Another important (and relevant to this competition) is the chat history between two users (more on it later).
At the front-end, we already built an Android app which allows users to post their trips, also book other people's trips. iOS app is being built, and will be released in a month's time.
Challenges we ran into
The first challenge is the trip-matching algorithm. We have to consider multiple factors such as:
- Waypoints of the trips, especially if a trip is just part of another one
- Time: a rider may depart quite a while ago but he still can pick up a passenger en route, because his trip is long enough that he hasn't arrived at the passenger's departure point yet. In that case we have to come up with a reasonable travel time estimation algorithm.
The second challenge is the communication problem. It is NOT a technical problem, but rather a User Experience (UX) problem. From our field tests with early users, they DO NOT want to disclose their phone numbers to the public, even to potential fellow riders before they make their trips. So we decide that we only show phone numbers after the two sides agree to pair with each other. However, then how do they communicate before they agree to pair? We need to allow them to chat, that's the simplest but most effective solution. When we tested the chat function of our app, users are so delighted and feel more eager to use the app.
Then we face the third challenge, since MMX doesn't have chat history, all delivered messages are not retained, so when the users come back to the conversation, they can't see the history. We have to build that function ourselves, by saving all the messages that belong to chat participants, and retrieve them when needed.
Accomplishments that we are proud of
- Build a well-functioning app in a short time (3 months).
- Integrate Magnet chat function into our app, and build message history function. All in less than 3 weeks.
What we learned
We shouldn't build everything from scratch, that takes a hell of time. Thanks to MMX server and SDK, our job is much easier. At the end of the day, bringing a seamless experience to our users is more important than going experimenting with all the stuff we are not strong at.
What's next for PinBike, bike-pooling:
- iOS version is coming out in late November
- Find more users on both sides of the market
- Expand geographically, currently we are building solutions for Vietnamese cities (Ho Chi Minh, Hanoi, Danang), so the list of popular locations are restricted to those in such cities. That said, the functionality should work everywhere now.
Log in or sign up for Devpost to join the conversation.