Rideaway

Rideaway Icon
Figma Mock-ups of UI

Inspiration

In our school district, school transportation is highly variable. With limited funding, buses are often canceled. This leaves just about 800 bus-dependent students without regular transportation to and from school. The fact that, at times, a large portion of our school does not consistent transportation for their education motivated us to fill this transportation void.

What it does

Rideaway seeks to fix this issue by connecting students in need of rides to parent or student drivers who can provide them. Thanks to its simple and intuitive design, Rideaway allows ride requests to be made. To start, a Rideaway user uses their phone number and a subsequent SMS verification code to log in to the app. The user can make a request, providing information like their name, pick-up address, and pick-up time. Potential drivers can access the Home page (by navigating to the bottom menu bar) on the app that includes all current requests (within the past 6 hours), choosing to accept or deny them. All requests include the data that the requester inputted when creating a request. Should a request be accepted, the requester is notified and secures a ride! The requester's request then is cleared among all Rideaway users' apps. To ensure that the app works for drivers as they want, there are several options in the Settings page of the app, such as accepting push requests, setting a maximum distance for driving, and enabling app notifications.

How we built it

For the front-end of the application, we used Swift (on XCode). On the back-end of the application, we used Express, Node.js, MongoDB and Twilio. MongoDB Atlas helps us store user data with requests and Twilio is used to verify users so they can properly use the app. For prototyping, we used Figma to create UI mockups and translated that into Swift. Our Node server is hosted on AWS.

Challenges we ran into

Learning how to integrate our backend languages (node.js, express.js) with Swift was something none of us had ever done before, so the experience of doing so was new but still rewarding. Additionally, setting up a publicly hosted server on AWS proved challenging with these time constraints.

Accomplishments that we're proud of

API usage, the app functionality as a whole, and Twilio integration all were aspects of our project that we felt the most proud of.

What we learned

Our biggest takeaway from this hackathon was the value of determining a concrete course-of-action. After the opening ceremony, we talked about various ideas that we had and ultimately chose one based on its feasibility. Afterwards, we discussed about the direction we wanted the app to go in, what features we wanted it to have, and smaller aspects to include at a later point (i.e. aesthetics). It was this sort of developmental analysis that really made it simple for us to know exactly what we needed to do at a given point in time: it was, in effect, a proper prioritization list. After having finished the project, we realized that had we not meaningfully determined a relevant course of action, we would have had a much more difficult time developing Rideaway.

What's next for Rideaway

Rideaway is an app with lots of potential; given more time, Rideaway can integrate with Google Maps and even provide drivers with optimized routes to pickup multiple people. Additionally, the security of Rideaway could be heightened by adding an authorization system: storing and utilizing Json Web tokens would make Rideaway more secure.