Inspiration
Grocery labels have a lot of information, but they do not always make it easy to compare two products. Serving sizes can be different, ingredient lists can be confusing, and the “best” choice depends on what matters to each person.
We built BareLabel to make grocery decisions feel simpler. Instead of giving every product one universal health score, BareLabel lets people compare products using the same amount and choose what they care about, such as a balanced option, more fiber, or less sodium.
What it does
BareLabel helps users search a small catalog of bread and cereal products from two simulated Walmart branches. Users can:
- Search for bread or cereal
- Change the simulated store location
- Rank products based on their nutrition priority
- View nutrition facts using an equal-weight amount
- Select two products and compare them side by side
- Explore the ingredients in each product
- See simple explanations for what ingredients usually do
- View missing or unverified information honestly The rankings are a comparison tool, not a universal health rating. Store availability is also clearly marked as simulated and does not represent live Walmart inventory.
How we built it
We built the frontend with React, TypeScript, and Vite. We used GSAP for small animations and transitions while keeping the website fast, accessible, and easy to use on mobile.
The backend was built with Python, FastAPI, and Pydantic. It handles product filtering, nutrition normalization, and ranking. Product nutrition is converted to the same reference amount, 50 grams for bread and 40 grams for dry cereal, so comparisons are fair.
We also created a shared API contract before building the two sides. This helped us keep the frontend and backend consistent while working separately. The frontend is hosted on Vercel and the API runs on Render.
Challenges we ran into
One of our biggest challenges was comparing products with different serving sizes. Comparing the numbers printed on two labels directly can be misleading, so we had to normalize the nutrition data to an equal weight.
Another challenge was making the rankings useful without acting like there is one perfect food for everyone. We solved this by letting the user choose a priority and by showing strengths and tradeoffs instead of only showing a score.
Connecting the frontend and backend also took careful testing. We worked through API response validation, CORS settings, loading states, timeouts, missing values, and stale requests when users changed filters quickly.
Ingredient lists were another challenge because they can include nested groups and unfamiliar names. We organized ingredients into simple groups and added short explanations without making medical claims.
Accomplishments that we're proud of
We are proud that BareLabel is more than a static design. The frontend connects to a working API, products can be searched and ranked, and users can compare two options using the same amount.
We also built clear error and retry states instead of silently switching to sample data. The app supports keyboard navigation, reduced motion, responsive layouts, and honest labels for simulated or unverified information.
Most importantly, we made a nutrition tool that explains its limits. It helps users understand tradeoffs without pretending to make the final decision for them.
What we learned
We learned that showing more data does not always make a product easier to understand. The harder part is choosing what information matters and explaining it clearly.
We also learned how important it is to agree on an API contract before splitting frontend and backend work. That made integration much smoother and helped us catch data problems early.
Building the comparison system taught us that serving size, missing values, and user priorities can completely change how nutrition data should be presented.
What's next for BareLabel
Next, we want to expand the catalog beyond bread and cereal, improve the ingredient explanations, and complete manual verification of the product information.
We would also like to connect to an authorized source for real store availability instead of using simulated branches. Other future ideas include barcode scanning, saved shopping lists, more nutrition priorities, and better support for dietary needs.
Our goal is to keep BareLabel simple while helping more people understand what goes into their cart.
Log in or sign up for Devpost to join the conversation.