AI Food Swap App – OffRamp

Overview

OffRamp accepts a current food intent, target constraints, and user preference profile, then returns ranked swap options that are easier to adopt than rigid substitutions. The design goal was to produce recommendations that users are likely to follow in real life, where convenience, culture, and availability often matter more than textbook nutrient optimization.

I intentionally scoped the first version around decision support rather than full nutrition tracking. That kept the product fast and focused: users open the app, enter what they are about to eat, and immediately see better alternatives with clear tradeoffs. The architecture was built to support iterative ranking improvements as more feedback data is collected.

Problem

Many nutrition apps fail because they ask users to completely replace habits with idealized meal plans. This creates high cognitive load and low adherence. People usually need incremental transitions that respect taste, budget, location, and preparation constraints. Without that realism, recommendations are technically correct but behaviorally ineffective.

From an engineering perspective, recommendation quality is constrained by data consistency. Food names, portion units, and nutritional labels are messy across sources. A reliable product requires normalization before ranking, plus feedback loops to adapt suggestions over time. The problem was to build a recommendation engine that stays practical despite imperfect data and diverse user contexts.

Approach

I implemented a rule-and-score hybrid recommender. Candidate swaps are generated from a curated food mapping layer, then ranked by weighted criteria: nutritional delta, user preference similarity, cost/access assumptions, and friction score. The friction score penalizes unrealistic shifts to improve adoption probability.

The API design emphasizes fast response and explainability. Every recommendation includes a concise reason string so users understand why the swap is suggested. This transparency is critical in health-adjacent products where trust drives usage. I also separated inference logic from transport code, making it easier to adjust scoring without touching API contract behavior.

Architecture

OffRamp uses FastAPI for backend inference and PostgreSQL for profile, feedback, and normalized nutrition records. The frontend is React-based and optimized for short interaction loops. Docker packages backend services for consistent deployment and reproducible local environments.

To support iteration, I structured the system around versioned recommendation profiles. This allows scoring changes to be tested and compared without breaking historical analytics. Recommendation outputs are logged with version metadata so directional improvements can be measured over time.

• - React interface for quick food-intent input and ranked swap output cards.
• - FastAPI service exposing recommendation endpoints and explanation payloads.
• - PostgreSQL schema for user preferences, food normalization, and feedback events.
• - Preprocessing scripts to standardize food names, portions, and nutrient fields.
• - Weighted ranking module combining nutrition, preference fit, and friction scores.
• - Dockerized backend with environment-specific config for local, staging, and production.
• - Optional Redis caching for repeated high-frequency swap queries.

What I Built

I built the full user journey from input capture to recommendation refinement. Users can provide current meal intent, select constraints such as calorie targets or dietary restrictions, and receive ranked alternatives with quick rationale. Each accepted or dismissed suggestion becomes a feedback signal that can tune future recommendations.

A key part of the build was data handling. I created normalization and mapping utilities to reduce duplicate food entities and inconsistent measurement units. This significantly improved ranking stability. On top of that, I added API-level validation to prevent malformed inputs from polluting feedback analytics.

• - Input model for current food, constraints, and personal preference context.
• - Recommendation engine endpoint with ranked results and explanation strings.
• - Feedback capture flow for accepted, skipped, and manually adjusted swaps.
• - Food normalization pipeline handling aliases, portion conversion, and category mapping.
• - User profile persistence for repeated sessions and preference continuity.
• - Admin/debug tools for score weight tuning and recommendation inspection.
• - Deployment scripts for container build, migration, and API startup orchestration.

Challenges & Tradeoffs

The main tradeoff was precision versus adoption. A nutritionally optimal suggestion can fail if it is culturally irrelevant or hard to source. I addressed this by weighting recommendation practicality and exposing transparent rationale. This reduced theoretically perfect but unrealistic outputs and improved the likelihood of sustained behavior change.

Another challenge was balancing latency with scoring richness. Complex ranking improves quality but can slow response times. I profiled the pipeline and moved expensive normalization work earlier in the flow. Caching repeated candidates and precomputing common mappings kept API responses fast enough for in-the-moment decisions.

Results

OffRamp delivered a usable prototype that helps users make immediate, lower-friction diet improvements. In directional testing, users preferred recommendation sets that included clear rationale and culturally familiar alternatives over generic healthy-food lists. The product succeeded by supporting gradual transitions rather than demanding abrupt habit replacement.

The project also sharpened my ability to build explainable AI systems where product behavior must be practical and transparent. I improved scoring design, data normalization discipline, and backend performance optimization. The architecture is now positioned for expansion with richer nutrition datasets and longitudinal adherence analytics.

Tech Stack

• FastAPI
• React
• PostgreSQL
• Docker
• Redis
• Pandas
• Vercel

The implementation stack includes FastAPI for inference endpoints, PostgreSQL for normalized data and user profiles, React for frontend interactions, and Docker for reliable deployment packaging. Python data tooling supports preprocessing and scoring calibration.

Deployment strategy is straightforward and production-minded: build container images, run database migrations, deploy API service, then publish frontend. This sequence prevents schema mismatches and keeps release risk low. Observability hooks around endpoint latency and recommendation acceptance were added to guide ongoing optimization.

Links

The repository includes recommendation logic and API design patterns used in this case study. I can also share implementation guidance for teams building explainable suggestion systems in healthcare or sustainability contexts.

For collaboration, use the contact page. I am open to freelance and full-time roles focused on intelligent product engineering.