Inspiration

Food logging has a strange contradiction: people need it most on busy, imperfect days, but those are exactly the days when opening a spreadsheet-like nutrition app feels impossible.

We wanted to build something calmer. ICJ started with a simple question: what if tracking carbs felt less like accounting and more like getting a small piece of useful guidance at the right moment?

That led to Intelligent Carb Juggler—a mobile-first companion that helps people capture food quickly, understand the day in context, and keep moving without labeling meals as “good” or “bad.” Evi, our small guide character, gives the experience warmth while the underlying numbers remain explicit and verifiable.

What it does

ICJ turns three common inputs into a reviewable food entry:

  1. Scan a packaged-food barcode. ICJ retrieves the product image, brand, serving, calories, and macros from Open Food Facts.
  2. Show ICJ a meal photo. A low-cost OpenAI vision model returns only a short list of probable food names. The user then confirms a real Open Food Facts match before nutrition is populated.
  3. Type an everyday food name. Search suggestions appear as the user types; selecting one autofills its available nutrition and product image.

The user stays in control throughout. They can change the serving, see nutrition recalculate, choose a meal, and review everything before saving. The Today view combines energy and macro progress with a seven-day chart, a consecutive-day rhythm, and a concise GPT-5.6 coach insight. History keeps images, sources, filters, and editing available after the moment has passed.

How we built it

ICJ is a mobile-first Next.js PWA written in React and TypeScript. Credentials authentication uses signed, HTTP-only sessions, while MongoDB stores accounts, goals, food history, nutrition snapshots, cached food results, and cached coach responses.

Open Food Facts is the source of product nutrition. We normalize its sometimes-incomplete community data into one internal food shape and cache successful results to keep search responsive. Barcode capture uses ZXing in the browser, with a manual fallback for camera-denied or desktop environments.

The AI layer is intentionally bounded. The OpenAI Responses API identifies likely food names from a validated photo, but it never invents calories or macronutrients. A food entry only becomes saveable after the user selects or confirms a database-backed match. GPT-5.6 Luna turns deterministic seven-day aggregate statistics into a structured, supportive reflection; it does not diagnose or prescribe.

Serving updates use a transparent scale factor:

$$ r = \frac{q_{\text{chosen}}}{q_{\text{reference}}} $$

For each nutrient (n), ICJ recalculates the displayed serving as:

$$ n_{\text{chosen}} = n_{\text{reference}} \times r $$

The seven-day carb view compares daily logged carbs (c_d) with the editable target (g):

$$ \text{weekly adherence} = \frac{1}{7}\sum_{d=1}^{7}\min\left(1, \frac{c_d}{g}\right) $$

We kept this mathematics visible in the interface so the insight is understandable rather than mysterious.

How we used Codex and GPT-5.6

Codex was our agentic product and engineering partner, not a one-shot code generator. We asked it to operate through product lead, UI/UX designer, integration engineer, security reviewer, and QA roles. It translated the initial mobile brief into a staged plan, established the capture → identify → confirm → save → review loop, designed the interface and motion system, integrated MongoDB and external APIs, generated and optimized mascot-led imagery, seeded realistic demo data, tested phone-sized interactions, and automated the end-to-end demo with Playwright.

Codex also challenged the product boundary that became central to ICJ: AI may suggest what the food is, but it must not invent what is in it. Open Food Facts supplies nutrition, and the person confirms the match and serving before anything is saved. Codex repeatedly inspected the real application, refined spacing and image sizing, verified fallback states, and ran TypeScript, lint, test, build, secret-history, and end-to-end checks.

ICJ uses a deliberate two-model runtime. GPT-5.6 Luna powers the seven-day rhythm coach, converting aggregate metrics into a structured headline, observation, next action, and celebration. Its results are rate-limited and cached for six hours. gpt-5-nano handles low-cost food-photo identification at low image detail and returns probable names only. This split uses GPT-5.6 where nuanced reasoning and language add the most value while keeping frequent image identification fast and economical.

Challenges we faced

Food data is inconsistent. Open Food Facts is powerful and open, but community-contributed products can omit images, serving sizes, or nutrition fields. We built defensive normalization, clear source labels, timeouts, and cache fallback instead of pretending every result is complete.

Photo recognition is probabilistic. A model can see “rice bowl” while missing a sauce or portion detail. We redesigned the flow so AI proposes names, the database supplies nutrition, and the person confirms the match. That separation became one of the product’s strongest trust features.

Camera behavior changes by environment. Mobile camera access requires HTTPS outside localhost and can be denied by the user. Both scanning and photo identification therefore have obvious manual/upload fallbacks.

Useful insight without medical overreach. We wanted the coach to feel intelligent but not diagnostic. ICJ explains patterns using the user’s logged data and editable goals, avoids moral language, and positions its targets as general estimates rather than medical advice.

Making a data-heavy product feel alive. The final design uses restrained completion motion, responsive progress rings, seven-day charts, food imagery, and Evi’s presence at key moments. The challenge was creating delight without turning a daily utility into a distracting animation demo.

Accomplishments that we are proud of

  • A complete account → onboarding → goals → food capture → review → save → edit → history journey.
  • Three input paths—barcode, AI photo, and search—that converge on one consistent confirmation flow.
  • AI that is useful precisely because its authority is bounded.
  • Real product images and nutrition facts preserved in history.
  • A seeded seven-day demo account that makes the complete story judge-ready.
  • An installable mobile PWA with offline awareness and camera fallbacks.
  • A documented, verified Codex-led product and engineering process.

What we learned

We learned that the strongest AI product decision is sometimes deciding what the model must not do. Letting AI identify a likely name while requiring structured food data for nutrition made ICJ safer, more explainable, and easier to debug.

We also learned that caching is a product feature, not only an infrastructure optimization. A fast repeat search and a graceful stale-data fallback make an open community API feel dependable. Finally, we learned that small moments—an image appearing beside a match, a serving recalculating instantly, a completion card arriving after save—create more confidence than adding another dashboard metric.

What’s next for ICJ

Next we would add durable object storage for uploaded meal photos, production email delivery for password recovery, household-friendly shared goals, and opt-in reminders based on the user’s normal logging rhythm. We would also expand the coach with privacy-preserving trend comparisons while keeping every recommendation traceable to visible user data.

Share this project:

Updates