HairBase

  • React Native
  • Expo
  • FastAPI
  • PostgreSQL

Mobile app, built for Blasterhacks 2025, that matches users with hair products that are compatible with with their hair, and offers picture-based product lookup, powered by a crowdsourced catalog of hair products.

Background & BlasterHacks

HairBase was a hackathon project for BlasterHacks 2025 at the Colorado School of Mines in Golden, Colorado—my second hackathon experience. I worked with Ben Ferguson, Yusuf Morsy, and Elijas Sliva, and each of us, while meeting just hours before the hackathon began, played a key role in the success of our project.

Features

After opening the app for the first time, users are prompted with a few onboarding screens that record their preferences and hair type, as shown below. Upon completion, they will find a searchable list of hair products, as well as indicators that illustrate whether each product is compatible with the user’s hair and preferences.

Side by side screenshots of HairBase images

By swiping right, the user will find the product scanning page. By taking a photo of a hair product, it will be queried in the product catalog, so that a user can quickly check if it matches their hair as they shop. If the product is not found, they are prompted to add the product to the catalog, so that it is available for other users to find. The product scanning uses a FastAPI backend, and Groq an AI tool—and a company that sponsored BlasterHacks—that uses OCR and an LLM to read the product’s label.

Side by side screenshots of HairBase images

Finally, by swiping left, the user will see a list of the products they have scanned before, for easy access.

Challenges

The largest technical challenge that our team faced was the difficulty of getting accurate results from the OCR tools. Our idea was to use photos of the labels to generate search queries that could be used to find the products in our PostgreSQL database—which offers some full-text search solutions. However, these were also difficult to use, as adding too many search terms would return no results. We attempted to mitigate this issue by changing the prompts to the LLM, but I think it would have been better to look into a third-party full-text search product, such as Elasticsearch.

At 36 hours long, BlasterHacks was 50% longer than the other Hackathon I did—and the lack of sleep certainly took its toll on me. It was difficult to focus in such a collaborative environment, as I attempted to work with my teammates at the same time. However, this did lead to the use of some key organizational tools—like making a to-do list for the project, which helped us stay organized, and made sure each person always had something they could be working on, which was a struggle at HackCU.

I also spent too much time on small details, like animating the progress bar on the onboarding screen, or adding haptic feedback. These features were fun to add, and important for a real app, but certainly not for a hackathon project (the judges didn’t even hold the phone!), which is something I will take forward with me.

Fun (and Chaos!)

The nature of Hackathons (a short-lived project that is intended to show a proof-of-concept) makes it really fun to try silly solutions to problems. It certainly makes some things easier—we used local storage instead of adding authentication and a more complicated backend. But what I love most is that I get to break things down into their most simple parts, and come up with my own solutions, even when I know in the back of my head that they aren’t perfect.

For image hosting, we could have used an external service, like Firestore, or even imgur. Instead, I got to design simple image upload and retrieval endpoints by encoding images in base64 and storing them in an SQLite database—far from perfect, but it ultimately lets users upload images, and returns a link to a working image.

Tech

As I had been working with Expo and React Native for the weeks leading up to BlasterHacks, the stack was an easy choice for the project. The Expo Go app allows you to scan a QR code from your terminal to launch the app, without having to build anything. While it slightly limits the libraries you can use (they must be packaged with Expo Go), it makes it incredibly easy for everyone to get up and running, which is a great way to start off strong.

I also spent some of my time working on the FastAPI backend. I am really comfortable with Python, so the experience was fantastic, and I will choose (and have chosen) the same stack again.

Elijas used Docker and Coolify to deploy the FastAPI backend and the PostgreSQL database, which was a huge help for us, because we were all able to use the same database live, without having to install local copies. He also went through a lot of trouble to scrape Sephora’s catalog (by inspecting the network requests), which was super helpful, because it gave us most of the data we needed to kickstart the app.