-
-
Project Logo
-
Original Home Screen Design
-
Original Search Screen Design
-
Original Results Screen Design
-
Original Details Screen Design
Inspiration
We were inspired to create FastThru because we wanted our project to be something that every person on the team could see being applicable in their own life. Beyond simply being a fun and interesting concept, we all really believe that FastThru has potential to make our lives better, and anything with potential like that deserves pursuing.
Beyond simply seeing where an application to find drivethru food fast could make those days when we just really need some junk-food much better, we found that fast food chains themselves could really benefit from the services that FastThru has the potential to provide. With Chick-fil-A reporting a loss 30% of potential customers due to too long drive-thru lines, there is really a need for our project.
What it does
FastThru is a mobile web application that take gives users an accurate approximation of local drive-thru wait times. The user interacts with a search query, through which we narrow down local drive-thru's and show them only restaurants that match the criteria. Those restaurants are shown on a map, represented by a red, yellow, or green pin according to our calculated estimated wait time.
How we built it
We built this FastThru using the Node.js environment and the Express framework on the back-end, and Figma, React, Javascript, HTML and CSS on the front-end. On top of this, for the bulk of our project, we accessed the INRIX Trips API, and supplemented this with the Yelp API and Google Maps API to create our search and map features.
Our team of five broke into two teams, with Aaron and Liam working on the front-end, and Asad, Kim and Megan working on the back-end for the bulk of the hackathon.
Challenges we ran into
On Saturday night, the Trips API went down. This gave us a huge setback, forcing us to reevaluate the scope and direction of our project, even at points considering scrapping all that we had and starting from scratch with only a few hours left. We managed to create a working project with what we had, but inaccessibility of the API severely set us back.
While this was our primary challenge, we did have some smaller hurdles as well. This was most of the team's first time programming in JavaScript, and most of us had never interacted with an API before. These learning curves translated into a slow first few hours, but as we became more comfortable with the workflow, our pace picked up.
Accomplishments that we're proud of
By the end of this hackathon, we produced a beautiful UI, an extensive presentation, and a working project. On top of this, we're all very proud of ourselves for our success in learning and experimenting with new languages and frameworks, including Express, JavaScript, APIs, graphQL, and more.
What we learned
First and foremost, we learned a lot about the importance of communication within our team. From using git to share files in a team environment to continually checking-in to make sure that we're all on the same page, communication is truly key in this environment, particularly since hackathons emphasize efficiency. Beyond this overarching and constant presence, we each learned new languages and frameworks, including Express, JavaScript, APIs, graphQL, and more.
What's next for FastThru
In the future, we hope to take this product first, of course, and make our conversion of cars to customers more accurate; this would include differentiating between cars on passing roads or parked in the parking lot from those in the actual drive-thru line, getting chain-specific and location-specific time estimates, and averaging a wider dataset of Trips. But beyond that, our next step would be to expand the scope of the product beyond the single city of San Francisco and historical data analytics. We’ve also gotten a suggestion to add a feature of predicting internal wait times, and we would really love to implement that when we have the time. Additionally, we hope to be able to move beyond our reliance on external APIs and create our own database of restaurants, most likely implementing a mongoDB database, and to rewrite our own internal APIs to be in graphQL.
Outside of technical improvements, we see this project as having potential as a startup. If we were to take this project to market, we would plan to adopt a B2B business model. With that in mind, we would facilitate this interaction by implementing an enterprise interface that would provide chains with analytics of trends in their drive-thru wait times so they can be more equipped to combat their revenue loss in the future.
Log in or sign up for Devpost to join the conversation.