Photograph a meal. AI identifies it and logs the calories — no manual entry, no searching a food database.
Manual calorie tracking dies within a week — not from lack of discipline, but because typing every meal into a search box is friction nobody sustains. Existing tools optimize for database-lookup accuracy, not for how little effort a person will actually tolerate three times a day.
Look at what logging one lunch actually costs. Open the app, search “chicken rice,” scroll a list of near-identical entries with wildly different numbers, guess which one matches what's in front of you, pick a serving size in grams you have no way to measure, then repeat for everything else on the plate. A minute or two, three times a day, for a number that was approximate the moment it was entered.
So people skip the awkward meals first, then the busy days, and within a fortnight the log has holes in it. An incomplete log isn't just less useful — it's misleading, because the missing entries are never random. The problem was never accuracy. It was that the interface asked for more effort than the information was worth.
A mobile app where the entire input mechanism is a photo. Point the camera at a meal, and the model identifies what's on the plate and estimates calories and macros automatically — the tracking step disappears into something that takes five seconds instead of two minutes.
The model does the work a database lookup can't: recognising several foods in one frame, reading roughly how much of each is there, and returning a single structured record instead of asking the user to assemble one. No taxonomy to navigate, no serving sizes to convert. What lands in the log is a meal, not a search result.
Built and deployed end-to-end — proof of shipping multimodal (vision + LLM) product work, from camera capture through backend inference to persistent storage.
One photo, one structured record.
Four stages between pointing a camera and having a day's intake on record.
A demo that labels a photo is a weekend. A system someone uses every day is not.
A photo gives you area, not volume. Two plates of rice that look identical from above can differ by half again in what's actually there, and nobody photographs their lunch next to a reference object. Portion estimation is where this stops being classification and starts being judgement.
Real meals overlap, sit in bowls, and hide half of themselves under sauce. The model has to commit to a decomposition of the plate that holds up, rather than one confident label for the whole frame — and be roughly right about the parts it can only partly see.
The entire premise is that logging takes seconds. That puts a hard ceiling on how much inference fits between the shutter and the result, which in turn shapes what runs where, what gets cached, and what the app shows while it waits.
A photo-based estimate will never match a kitchen scale, and it wasn't built to. The comparison that matters isn't against a perfectly weighed log — it's against the log people actually keep, which is partial, back-filled from memory, and abandoned by the second week.
An approximate number recorded every day beats a precise number recorded for four days and then never again. Trends are what change behaviour, and a trend survives noise in individual entries far better than it survives gaps. Designing around that is why the input is one photo and not a form.
Less about breadth of applications, more about the capability it demonstrates.
Live and working — a full mobile-to-backend system proving multimodal (vision + LLM) products can ship end-to-end, not just as text-based AI integrations.