Building OopsCalorie: When Your AI Thinks Dinuguan Is Champorado 😂

Alfredoruru — Tue, 18 Aug 2026 03:29:45 +0000

I’ve been building a side project called OopsCalorie, an AI-powered calorie and meal tracking app.

The idea sounded simple enough:

User logs or takes a photo of their food.
AI identifies the meal.
Estimate calories and macros.
Save the entry.
Done.

Simple, right?

Well...

Then we started testing it with Filipino food. 😂

AI Meets Filipino Food 🇵🇭

One of the funniest parts of building OopsCalorie has been testing the food recognition.

At one point, our AI confidently looked at dinuguan and decided:

That's champorado.

Okay. I can kind of see where you were coming from. Both are dark, both can be served in a bowl...

But still. 😂

Then came bagnet.

AI:

Lumpiang Shanghai.

Bro.

Not even close. 😂

These bugs are funny, but they also exposed one of the more interesting engineering problems behind OopsCalorie:

Image recognition is only the first step.

Correctly identifying a meal — especially regional dishes — requires much more context than I initially expected.

The Real Problem Isn't Just Calories

When I started the project, I thought the difficult part would be estimating calories.

Turns out, before you can estimate:

You need to know what the food actually is.

And food can be surprisingly ambiguous from an image.

A photo might contain:

multiple dishes
sauces hiding ingredients
visually similar foods
regional dishes that aren't well represented in training data
different cooking methods
unknown portion sizes
ingredients completely hidden underneath other ingredients

Even humans sometimes need context.

"Is that pork adobo or humba?"

"Is that fried pork belly or bagnet?"

Now imagine asking an AI to determine that from pixels alone.

Building Around AI Instead of Blindly Trusting It

This changed how I'm approaching the system.

Instead of treating the AI response as absolute truth, OopsCalorie is evolving toward a workflow where AI provides an intelligent estimate while the user still has the ability to provide context and correct it.

We're experimenting with things like:

Image + user context

A short description from the user can dramatically reduce ambiguity.

Confidence scoring

If the system isn't confident about what it's looking at, it shouldn't pretend that it is.

Food candidates

Instead of saying:

This is definitely X.

The system can consider multiple possible foods before making the final estimate.

Filipino food awareness

This is particularly important for us.

A lot of calorie trackers are built around foods that are easy to find in international nutrition databases.

But Filipino meals aren't always that straightforward.

Try estimating the calories of someone's homemade adobo where every household has a slightly different recipe. 😅

The Stack

OopsCalorie is currently being built with:

React Native + Expo for the mobile app
NestJS for the backend
MongoDB for data storage
LLMs / multimodal AI for meal understanding and nutritional estimation

The goal isn't to build another massive nutrition database with an AI label slapped on top.

I'm more interested in exploring how AI can make food logging feel less like data entry.

Take a photo. Give it some context if necessary. Get an estimate. Correct it when needed. Move on with your day.

We're Still Testing 🧪

OopsCalorie is currently in the testing phase.

And that's exactly why I'm sharing it now.

I want developers and early users to break it.

Upload weird meals.

Upload Filipino food.

Confuse the AI.

Find edge cases I haven't thought about.

And yes, if you manage to make it identify lechon as a croissant, please send me the screenshot. 😂

The Android and iOS versions are coming soon.

Try / Follow OopsCalorie

🌐 Website
https://oopscalorie.com/

🧪 Become a beta tester
https://oopscalorie.com/beta-testers

📖 Development stories & experiments
https://oopscalorie.com/blog

I'm also open to collaborations with developers, designers, nutrition/fitness people, or anyone interested in experimenting with AI-powered consumer apps.

Building With AI Has Been... Interesting

One thing this project keeps reminding me:

AI can be incredibly impressive and incredibly stupid within the same five minutes.

And honestly, that's part of what makes building with it fun.

Every ridiculous result becomes another edge case.

Every edge case becomes another improvement.

And every improvement gets us a little closer to making OopsCalorie actually useful.

I'll be sharing more about the technical decisions, AI experiments, failures, costs, architecture, and the occasional food-recognition disaster as development continues.

Until then...

Dinuguan is not champorado.

We're working on it. 😂

ai #webdev #reactnative #nestjs #typescript

Component best practice question.

Alfredoruru — Wed, 07 Feb 2024 13:22:25 +0000

Hi everyone on my current job right now as a front end developer, my lead developer ask me to create a skeleton fallback components integrating the Skeleton component from MUI.

On every fallback component I created I always imported Skeleton component from MUI. But my lead told me to create a dumb component which encapsulates the Skeleton component and pass the same props as the Skeleton component from MUI and instead of using the Skeleton component from MUI I should use the dumb component I created.

So basically I just created a copy of the Skeleton component from MUI.

Are there any benefit of doing it?

Sample code

import { Skeleton } from "mui/material"

export const OurSkeletonComponent = (props) => <Skeleton {{...props}} />

DEV Community: Alfredoruru