Before the hackathon, as we were brainstorming over the phone, we all had a common problem: There were all these receipts just lying around (see last photo). Within those receipts lied important information that when harnessed properly, could greatly benefit all of our financial well being, or at least remind us of our bad spending habits. At first I started typing all the data into a spreasheet, but that was too tedious for anyone who has a ton of receipts. Thus, ReceiptSafe was born, a modern solution to an age old problem.
What it does
ReceiptSafe takes a picture of your receipt, extracts all relevant financial information, stores it in our database, and allows you to retrieve all of that data easily, allowing you to conveniently track your spending habits and purchase history, all in one app. It also uses data visualisation to categorize and show where your money is being used.
How we built it
All our code was done on Android Studio, using Java for the Android app. We first used Google's Image recognition API, which needed to have a text size of at least 12 pixels, however, most receipts use smaller text, and thus we switched over to other API's (we had to switch between 3 API's as described below). We also used Firebase for the backend databases. We used smartsheet to plan our time around the Hackathon's schedule, such that we were able to enjoy workshops, sponsor meet and greets and of course, the food.
Challenges we ran into
We had some trouble implementing the image recognition functionality, perfecting the database solution, and tying all of the components together to form one cohesive product. Originally, we used Firebase for our backend but after some difficulty, a mentor recommended to use Firestore instead. Which lead to a new problem, that is Firestore was not compatible with Google's Mobile Vision API so we had to revert back to Firebase (this took many hours, as we were all new to Firebase/Firestore). Additionally, the Google Recognition API that we were using did not work as intended, during the hackathon we discovered that it was designed for larger text. For optimal use, we had to have 12 pixel text or larger. Hence, the API would only work when the image was taken from a couple of centimeters above the receipt, needles to say that was impractical. As we were running out of time at this point, we quickly switched to another API: infrrd.ai, however, we were not able to secure an API key to access it's services. Finally, we switched to taggun.io, which was able to save us!
Accomplishments that we're proud of
We were constantly challenged, with bugs and errors at every corner. we had to really think outside the box, and go through hundreds of pages of official documentation. We are also proud that, we all walked into this hackathon with no Android Development experience and no knowledge of how Firebase works. We were able to learn, code and present a product in only 24 hours. It was quite the experience and we are proud of the fact that we were able to finish the product, and have a MVP that we can use ourselves!
What we learned
We learned the value of perseverance and hard work. The ability to resist the urge of being mediocre is a very valuable skill to have, and we definitely learned that. One of the key takeaways from the series of keynote speakers in the opening ceremony was that perfect is the enemy of good. In undergoing this project, we had a specific blueprint that we believed would take us directly to the finished product. However, like all plans, they can sometimes go awry, and during the process of creating this project, we had to deviate from that blueprint in order to come up with a minimum viable product that at least somewhat resembles the original conception, but that is okay. It is okay to not be perfect, it is okay to not follow the idealized plan, it is okay to have bumps in the road. That is the most valuable lesson we learned from this Hackathon.
What's next for ReceiptSafe
We would like to refine all existing core offerings, as well as implement new features. There are many things you can do with financial data, and unfortunately, it is not possible to explore the scope of these things within 24 hours. Pursuing the implementation of the features makes the app much more helpful to the average consumer. We would like to continue developing this project, and make it meet our initial expectations. It started off as a solution to a problem faced by the team, and with some more work and features, the app can be one that we, and maybe other users, use daily. I for one would like to continue developing and expand it to iOS devices too (-Iyad)