Inspiration
SafeBite started with a real family problem: checking products becomes much more complicated when different people in the same household manage different allergies, intolerances, sensitivities, skin triggers, dietary restrictions, and ingredient concerns.
I wanted to build something that could answer a more personal question than simply, “What ingredients are in this product?”
SafeBite is designed to help answer:
“What does this product mean for the person who is actually going to use it?”
What it does
SafeBite helps users check products against personalized safety profiles.
Users can scan a barcode, photograph packaging, upload a product image, search, or enter product information manually. SafeBite evaluates the available product and ingredient information against the selected person’s medical allergies, sensitivities and intolerances, dietary and personal rules, and custom ingredients to avoid.
The app also preserves product identity, source information, confidence, and ingredient evidence so users can understand not only the result, but what that result is based on.
One of SafeBite’s core principles is that uncertainty should be visible.
If product information is incomplete, SafeBite does not manufacture certainty. It can return Needs Review, explain what information is missing, and tell the user when the physical label, manufacturer, or another source should be verified.
SafeBite also distinguishes food from topical products so food-specific dietary rules are not incorrectly presented as verified compatibility for products such as deodorant or skincare.
How we built it
SafeBite is a mobile application built with React Native, Expo, TypeScript, Supabase, and PostgreSQL.
Development focused heavily on the reliability of the core product-checking experience: barcode identity, mobile image capture, product-photo preservation, ingredient evidence, profile-specific evaluation, data completeness, source transparency, confidence, saved-product workflows, privacy controls, and recovery when a scan or lookup cannot be completed normally.
For Shipaton 2026, I took SafeBite from an existing development project through production iOS QA and App Store submission.
RevenueCat and the Family+ entitlement infrastructure were also developed as part of the project. The current first-release App Store binary is intentionally free-first, with paid Family+ purchasing disabled while Apple’s Paid Apps Agreement and tax-form setup are resolved.
The goal is to eventually support premium household and convenience features without placing essential product-safety information behind a paywall.
Challenges we ran into
Some of the most important challenges were not flashy features. They were trust and reliability problems.
Real-device mobile QA exposed issues involving camera and barcode behavior, image handling, product identity, incomplete ingredient information, recommendation behavior, category-specific evaluation, saving and persistence, keyboard accessibility, privacy controls, and situations where an action could appear successful without enough verification behind it.
One particularly important lesson came from incomplete product data.
A product could have some ingredient information available without having enough information to support a reliable safety conclusion. SafeBite had to learn the difference between “no concern found in the information we have” and “we have enough information to call this safe.”
That distinction became a major part of the product.
Testing also exposed cases where broad keywords could create incorrect conclusions, such as treating every use of the word “bacon” as pork. Those cases pushed SafeBite toward more context-aware evaluation instead of simplistic keyword matching.
For a product intended to help people make more informed decisions around allergies, intolerances, sensitivities, dietary needs, and ingredients, those failures matter.
That testing changed the way I approached the product. SafeBite increasingly treats data provenance, uncertainty, context, accessibility, and recovery behavior as part of the user experience rather than hiding those limitations from the user.
Accomplishments that I'm proud of
I'm proud that SafeBite has grown far beyond the idea of a basic barcode scanner.
The project now combines personalized safety profiles, barcode and photo-based product checking, product-identity safeguards, category-aware evaluation, source transparency, confidence and completeness handling, saved-product workflows, data export, in-app account deletion, and mobile recovery paths designed around what the app actually knows and what it cannot verify.
I’m especially proud of the product’s approach to uncertainty.
SafeBite can say Needs Review instead of forcing every product into a simple safe-or-unsafe answer. That may seem like a small detail, but for a product dealing with allergies and ingredient concerns, being willing to say “we don’t know enough yet” is an important part of earning trust.
I’m also proud that much of this progress came from repeated testing on a real iPhone, finding problems that were not obvious during development, and continuing to repair and validate them rather than designing only for the ideal scenario.
SafeBite 1.0.0 (3) completed physical-device QA and was submitted to Apple App Review.
What I learned
One of the biggest lessons from building SafeBite is that trust itself is a product feature.
A polished interface means very little if the information behind it cannot be understood, traced, or trusted.
Building SafeBite pushed me to think more deeply about data provenance, confidence, product context, mobile reliability, accessibility, error recovery, privacy, and how to communicate uncertainty without overwhelming the user.
I also learned how much real-device testing can reshape a product.
Some of SafeBite’s most important improvements came from discovering what happened when the real workflow did not behave the way the original design expected, and then treating those failures as product-design problems, not just technical bugs.
Another major lesson was that a sustainable business model does not have to put the most important safety information behind a paywall. The long-term plan is to keep essential product checking available while using premium features to support the broader household and convenience experience.
What's next for SafeBite
SafeBite 1.0.0 (3) has completed physical-device QA and has been submitted to Apple App Review.
The immediate next step is public release once Apple approval is complete.
The first release is intentionally free-first while the Paid Apps Agreement and tax setup for Family+ are resolved. Once that work is complete, the next phase will include truthful RevenueCat-powered Family+ subscriptions and household entitlement behavior.
After launch, I want to collect real-world usage and feedback, improve Better Options and recommendation relevance, strengthen product-source coverage, continue improving household and caregiver workflows, and make SafeBite even better at explaining what it knows, what it does not know, and what the user should verify next.
The long-term goal is to make everyday product decisions easier for people managing allergies, sensitivities, intolerances, dietary restrictions, and other ingredient concerns without sacrificing honesty for simplicity.
Built With
- expo.io
- ios
- javascript
- native
- postgresql
- react
- supabase
- typescript
Log in or sign up for Devpost to join the conversation.