I have been building MetricSync, an iPhone AI food logging app, and one lesson keeps showing up:
The hard part is not choosing photo, barcode, or text.
The hard part is choosing the right one for the moment the user is in.
A lot of AI food logging demos make the camera feel like the whole product. Point at a plate, get a result, done.
That is a good demo. It is not the whole day.
Real logging has different shapes:
- a packaged snack with a barcode
- leftovers where the user already knows what it is
- a restaurant bowl where the photo is useful but incomplete
- a homemade meal where text is faster than aiming a camera
- a messy plate where the first AI guess needs a quick correction
If the app treats every meal like a camera moment, the user has to fight the product.
Capture mode is part of the UX
I started thinking about photo, barcode, and text less like features and more like paths through the same job.
The job is not "use AI."
The job is "log this before I lose patience."
That changes the interface.
For a packaged food, barcode should probably win. The user is not asking for creativity. They want the obvious item quickly.
For a plate, photo should probably win. The user does not want to type every ingredient before eating.
For leftovers or a simple homemade meal, text can be fastest. "Chicken rice bowl" may be a better first input than a dark photo inside a container.
For anything ambiguous, correction has to feel like part of the happy path, not an error state.
The first result is a draft
The biggest mental shift for me was treating AI output as a draft.
A draft can be useful even when it is not perfect. It gives the user a starting point. But the product only feels good if the next move is cheap.
That means the app needs to make these actions easy:
- swap an item
- adjust a portion
- add a missing ingredient
- replace the input method
- save and move on
If correction feels heavy, the user stops trusting the app.
If correction feels normal, a close first guess can still be useful.
My current rule
When I am evaluating a food logging flow now, I ask:
Can the user recover in one small step if the first input was wrong?
If the answer is no, the capture mode is not really flexible. It is just another funnel.
This applies outside food logging too. Any AI product that accepts messy real-world input needs a graceful second move.
The model can be impressive, but the product wins when the recovery path is boringly easy.
That is the direction I am taking MetricSync: iPhone food logging from photo, barcode, or text, with correction treated as a normal part of logging instead of a failure.
If you want to try it, MetricSync is here: https://metricsync.download
It has a 3-day free trial, then it is $5/month.
Top comments (0)