Turning a meal photo into an editable food entry, and why the review step matters more than the model

Disclosure: I'm the developer of Mealumo, the iOS app this post is about. This is a write-up of the design decisions behind it, not a review. The link is at the end. If you think we got a tradeoff wrong, I'd like to hear it in the comments.

This post was drafted with AI assistance and reviewed before publishing.

The problem

When people give up on calorie trackers, it's usually not the nutrition that beats them. It's the data entry. You type "chicken salad", scroll through dozens of near-identical entries, guess a portion, then do it all again for the dressing, the bread and the drink. Doing that three to five times a day is a lot to ask.

So the idea behind Mealumo is simple: let a photo start the entry. You take a picture of your plate, or pick one from your photo library, and the app proposes ingredients, portions, calories, protein, carbs and fat. Then you fix whatever is wrong and save it.

That last sentence turned out to be the real product.

The flow

Here's how an entry gets made:

  1. Capture. Use the camera or choose an existing photo. Library import means a meal photographed at lunch can be logged in the evening.
  2. Analyze. The photo goes to an external AI service, which estimates what's on the plate: individual ingredients, their portions, and the calories and macros for each. This step needs an internet connection.
  3. Review. The estimate is shown as a list of ingredients you can edit, not as one final number. You adjust portions, edit ingredients, and add anything that's missing.
  4. Save. The entry goes into a daily journal, which adds up calories and macros against your daily targets.

Around that core sit the less glamorous parts: food search for adding ingredients by hand, a water log, a weight log with progress over time, recipe ideas, and daily nutrition targets estimated from your goals, body measurements and activity.

Why one number is the wrong output

The tempting version of this feature is the demo version: photo in, "640 kcal" out. It looks great, but it fails in a way the user can't fix.

Suppose the app says 640 and you know the portion was bigger. What do you edit? If you overwrite the total, the macros stop adding up, and you still don't know which part of the meal was wrong.

Breaking the estimate into ingredients × portions fixes that. Most mistakes on a food photo are local: the amount of rice is misjudged, or a sauce turns out to be cream-based rather than tomato. When the output is a list, you correct the one wrong line and the totals follow. The model doesn't need to be perfect. It needs to be a better starting point than an empty search box.

An itemized estimate also has practical benefits on the app side. Each line can be shown, checked and edited on its own, which is much easier than parsing a paragraph of free text.

What a photo physically can't tell you

The model isn't the hard limit. Some information just isn't in the pixels:

  • Fats and oils. A tablespoon of olive oil is roughly 120 kcal and becomes basically invisible once it's cooked into the food. The same goes for butter on vegetables and oil in a dressing.
  • Portion depth. A photo taken from above shows area, not volume. A deep bowl and a shallow plate can look the same.
  • Hidden layers. Burritos, sandwiches, casseroles: anything mixed or wrapped.
  • Recipes. "Pasta with sauce" might be a light tomato sauce or a heavy cream one.
  • Drinks. Two cups can look alike and contain very different things.

You can't engineer these away. What you can do is be honest about them and make corrections cheap. That's why the App Store listing says outright that nutrition estimates may be inaccurate and should be reviewed before use, and why reviewing the estimate is part of the flow, not an optional extra.

An app that users trust a little less, so they check for the oil, is better than one they trust completely until the numbers stop making sense.

Speed vs. trust

There's a real tension here. Logging only works if it's quicker than typing, and every confirmation step adds friction back.

These are the principles we designed around:

  • Show the estimate right away, and make it editable. The first thing you see after a scan should be something you can act on.
  • Treat portions as the main thing to correct. Portion size is what a photo shows least reliably, so adjusting it has to be easy.
  • Keep manual entry close by. Some meals don't photograph well, like a shake in an opaque bottle or a meal that's already half eaten. Food search covers those.
  • Never claim more precision than exists. An estimate should look like an estimate.

Privacy is a product decision, not a footnote

Meal photos are personal. Sending them to a third-party service is a real decision, and users should know about it. The Mealumo listing says plainly that meal photos, and the profile details needed to generate nutrition targets, are sent to an external AI service for processing. Putting that sentence on the store page, rather than burying it in a policy, is a small thing. It's still the kind of thing that decides whether people trust a health-adjacent app.

Not a medical app

A calorie tracker can easily slide into health claims. Mealumo is a general-wellness food journal. Its targets are estimates, it doesn't diagnose or treat anything, and the listing says so. It doesn't promise weight loss, and I don't think a tracker should. What it can do is make the tedious part of paying attention to food take less time.

Takeaways for anyone building on vision models

  • Return structure, not a verdict. Itemized output lets users fix one item instead of throwing the whole result away.
  • Know what your input can't contain. For food it's oil, depth and hidden layers. Every domain has its own version of this.
  • Put the uncertainty in the UI. A disclaimer helps, but an editable result communicates "this is a guess" better than any fine print.
  • Be explicit about where the data goes. Users notice.

Try it / tell me where it's wrong

Mealumo is free to download on iPhone (iOS 26+), with an optional PRO subscription for continued scanning and the full recipe collection:
https://apps.apple.com/app/id6811904664

It's new and has no ratings yet, so feedback counts for a lot right now, especially photos where the estimate is clearly off. If you want to try PRO, comment or DM me for a free PRO promo code.

And if you've built something on vision models with messy real-world input, how did you handle the cases where the answer simply isn't in the image?