Back to Products
Culin logo

Culin

The Food Decision Engine

MyFitnessPal plus ChatGPT, backed by a real nutrition layer.

Culin v1 is a full-stack mobile AI product that turns macro goals, taste preferences, restaurant/grocery context, and user history into one next-meal decision. This page breaks down the features, data pipelines, tools, and infrastructure behind it.

Culin decision screen

System Overview

Product surface backed by a nutrition decision stack.

The page is organized the same way the product is built: mobile client, API layer, nutrition data, AI reasoning, auth, and deployment.

Mobile App

React Native
Expo Router
TypeScript
React Navigation
AsyncStorage

API Layer

Next.js API routes
FastAPI
REST contracts
Request validation
Auth middleware

Nutrition Data

PostgreSQL
USDA/FatSecret
Pandas ETL
RapidFuzz
SQLAlchemy

AI Engine

OpenAI
Anthropic
Gemini
LangChain
RAG/vector search

Platform

AWS Cognito
JWT/OIDC
Docker
DigitalOcean
Env-based config

Feature Breakdown

Each product screen maps to a concrete engineering subsystem.

Food Decision Engine screen

Feature 01

Food Decision Engine

Feature

The core loop takes macro targets, time, taste, budget, location, and user intent, then returns one next meal instead of a ranked list of options.

How I Built It

I modeled the product around a binary order-or-cook decision. The mobile client collects constraints with typed React Native flows, the API normalizes those inputs, and the scorer weighs macro fit, time-to-eat, cost, preference match, and confidence before the LLM writes the recommendation.

Tools

React NativeExpo RouterTypeScriptNext.js API routesFastAPIOpenAI

Infra / Engineering

Typed request/response contractsServer-side scoring layerEnvironment-based model/provider config
Constraint collection lives in the mobile flow
Decision scoring runs before generation
LLM output is treated as presentation, not source of truth
Next-Meal Generation Pipeline screen

Feature 02

Next-Meal Generation Pipeline

Feature

Culin feels conversational, but the response is assembled from structured nutrition context, user memory, and validated output fields.

How I Built It

The generation path builds a compact context packet with remaining macros, diet rules, recent meals, preferred cuisines, and candidate foods. The model returns a meal card with reasoning, substitutions, macro estimates, and a next action. Validation keeps the response usable by the mobile UI.

Tools

OpenAIAnthropicLangChainLangGraphGoogle GeminiAWS Bedrock

Infra / Engineering

Provider adapter layerPrompt/version configurationJSON response validationFallback model routing
Structured context goes into the prompt
Generated meals map directly to UI cards
Provider swapping is isolated behind service adapters
Nutrition Data Layer screen

Feature 03

Nutrition Data Layer

Feature

The nutrition layer estimates calories, protein, carbs, and fats from real food data instead of relying on generic chatbot guesses.

How I Built It

I designed ingestion and matching around USDA/FatSecret-style datasets, normalized food names, serving units, and macro fields, then used fuzzy matching to connect user-friendly food descriptions to structured records. This lets the app show macro confidence and explain where estimates came from.

Tools

PostgreSQLPythonPandasNumPyscikit-learnRapidFuzz

Infra / Engineering

ETL scriptsCSV/TSV parsersSchema migrationsDockerized local services
Food records are normalized before retrieval
Fuzzy matching handles messy user language
Macro estimates are stored separately from generated prose
User Memory, Auth, and Protected State screen

Feature 04

User Memory, Auth, and Protected State

Feature

Culin remembers goals, preferences, allergies, diet rules, and meal feedback so recommendations improve without making users re-enter context.

How I Built It

The app separates local mobile state from account-backed state. Fast preferences can be cached on-device, while durable profile data and meal history live behind authenticated APIs. Cognito/OIDC and JWT verification protect user-specific endpoints.

Tools

AWS CognitoJWTOIDCAsyncStoragePostgreSQLSQLAlchemy

Infra / Engineering

Protected API routesAuth middlewareSecure token handlingEnvironment-scoped secrets
Onboarding answers become ranking signals
Feedback updates preference weights
Protected routes keep user nutrition history isolated
Order-or-Cook Handoff screen

Feature 05

Order-or-Cook Handoff

Feature

After the decision is made, the product turns it into an action: a restaurant-style order path or a grocery/cook path.

How I Built It

The backend keeps the handoff modular. Restaurant/menu matching, grocery list generation, recipe ingredients, and external links can evolve independently while the mobile UI renders the same action card pattern. That keeps Culin from becoming tied to one vendor integration.

Tools

FatSecret APIInstacart conceptsREST APIsGoogle PlacesNode pgFastAPI

Infra / Engineering

Integration service modulesExternal API configurationRetry/error boundariesManual curl endpoint checks
Order and cook use the same decision contract
Vendor integrations are adapter-based
The UI only needs a normalized action payload

Implementation Map

The engineering surface area behind Culin v1.

The project combines mobile app development, API contracts, AI orchestration, auth, data ingestion, and deployment work into one cohesive product.

React NativeExpo RouterTypeScriptNext.jsFastAPIPostgreSQLOpenAIAnthropicLangChainAWS CognitoUSDA/FatSecret dataDocker

React Native/Expo mobile client with route-based screens, reusable nutrition cards, and local persistence for fast onboarding state.

Next.js and FastAPI services split product-facing API work from heavier Python nutrition/data workflows.

PostgreSQL-backed food, user, and recommendation records with migration-friendly schemas and explicit validation boundaries.

Engineering Notes

What the project demonstrates

React Native/Expo mobile client with route-based screens, reusable nutrition cards, and local persistence for fast onboarding state.

Next.js and FastAPI services split product-facing API work from heavier Python nutrition/data workflows.

PostgreSQL-backed food, user, and recommendation records with migration-friendly schemas and explicit validation boundaries.

LLM provider layer supports OpenAI, Anthropic, Gemini, and Bedrock-style integrations without coupling UI logic to a single model.

Dockerized services and environment-based configuration make local testing, deployment, and API troubleshooting repeatable.

Active product

Food decisions, built as infrastructure.

View culin.ai