FoodRisk AI
Overview
FoodRisk AI was designed to help people make safer food choices by combining barcode scanning, AI-powered ingredient analysis, and personalized allergy profiles.
Rather than simply displaying nutritional information, the goal was to help users understand whether a specific product aligned with their personal dietary needs and restrictions.
The product combines traditional software engineering with modern AI capabilities, requiring thoughtful frontend architecture, backend integrations, and developer tooling designed to support an evolving product.
The Problem
Many existing food applications stop at presenting raw nutritional information.
The challenge here was different.
The application needed to interpret ingredients, explain potential risks, personalize responses based on individual user allergies, and present that information in a way that remained understandable to everyday users, not just people with technical or nutritional expertise.
It also required an administration platform capable of managing products, users, and AI behaviour while remaining maintainable for ongoing development.
My Role
I served as the primary software engineer responsible for building the frontend application and translating product requirements into a working platform.
Beyond implementing interfaces, I contributed to authentication flows, administrative tooling, AI integrations, developer logging, deployment workflows, technical documentation, and architectural decisions that improved long-term maintainability.
Responsibilities
Authentication and onboarding flows
Role-Based Access Control (Admin and Super Admin)
Admin Dashboard
Gemini AI Integration via Edge Functions
AI-assisted OCR (replaced traditional OCR)
Barcode scanning workflows
Ingredient analysis features
Recipe suggestions
Activity logging system
Developer error logging system
Analytics dashboard
CSV export
Product override management
Company settings
API key rotation system
Deployment support
Technical documentation
Engineering Decisions
Why Gemini replaced traditional OCR
The initial OCR approach produced inconsistent results because food packaging varies significantly in lighting, layout, and image quality. Rather than investing time in improving an increasingly unreliable extraction pipeline, I redesigned the workflow so Gemini Vision handled both text extraction and contextual interpretation simultaneously. The result was a simpler architecture that produced more meaningful, contextual outputs while eliminating the need for multiple processing stages.
Why centralized API key management
AI systems introduce operational problems that traditional web applications rarely face. Quota exhaustion, rate limits, and temporary service unavailability directly affect user experience in ways that are difficult to predict. I designed an administrative API key management system allowing multiple Gemini API keys to be registered and actively monitored. Requests automatically rotate between available keys based on availability, reducing service interruptions without requiring developer intervention on every failure.
Why internal logging before external observability
During earlier projects I learned that debugging production systems becomes significantly harder without visibility into user activity and application failures. Rather than immediately adopting an external observability platform, which would have required justification before the product proved its value, I introduced centralized activity logging and developer-focused error logging that provided immediate insight into system behaviour and helped stakeholders understand the long-term value of production observability.
Why Vercel for development, Cloudflare for production
Development prioritizes iteration speed. Production prioritizes reliability and security. During active development, Vercel provided rapid deployments and simplified the feedback cycle. Production infrastructure was intentionally planned around Cloudflare because its networking, caching, and security capabilities better align with what a healthcare-adjacent product requires at scale.
Architecture
Biggest Challenge
Integrating AI through Supabase Edge Functions proved significantly more complex than simply calling an external API.
The project introduced an unfamiliar class of problems: authentication failures, configuration mistakes, quota exhaustion, malformed responses, and intermittent AI service availability. Each failure mode required a different debugging approach, and the combination of a new AI provider, an unfamiliar edge computing environment, and a product timeline created sustained pressure throughout development.
Rather than treating each error as an isolated incident, I gradually redesigned the surrounding architecture: improving error handling, strengthening logging, and introducing automated API key rotation. The experience fundamentally changed how I think about integrating AI capabilities into production software.
What I Learned
"AI engineering extends beyond prompt writing."
Reliability, quota management, and failure handling are engineering concerns that shape system architecture.
"Observability saves development time."
Centralized logging paid for itself within days of implementation through faster debugging.
"Iteration produces better software."
The final architecture looked nothing like the initial implementation, and was better for it.
"Developer experience matters."
Tooling that makes debugging easier reduces frustration and improves the quality of decisions made under pressure.
"Reliable software is designed."
Reliability doesn't emerge from careful coding alone. It requires deliberate architectural decisions.
"Question the approach, not just the implementation."
Replacing OCR entirely was faster and more effective than optimizing a flawed pipeline.
Reflection
FoodRisk AI became the project where I began thinking less like a frontend developer and more like a software engineer.
It required balancing product requirements, AI limitations, backend integrations, and long-term maintainability rather than simply implementing the interfaces in a design file.
Many of the engineering decisions I carry into newer projects, including centralized logging, resilient API integration and thoughtful deployment planning, originated here.