I could have started Seasoned Pan’s meal estimator by connecting a camera to a vision model and asking for calories.
That would have produced an impressive demo and a dishonest product.
Instead, I put four awkward, ordinary food photographs in front of the proposed response format before building the feature: a homemade taco, a frosted cake, a restaurant sushi spread, and a festival bowl photographed in poor light. Each one exposed a different way a confident estimate could be wrong.
Those failures became the contract.
A Photograph Hides The Expensive Parts
The taco looked identifiable, but the important facts were invisible. The camera could not know whether the meat was turkey or beef, how much oil had been used, or that the tortilla was a lower-carbohydrate product.
The cake introduced a different problem. Recognizing cake was easy. Estimating the size of the whole cake and the fraction actually eaten was not.
The sushi photograph contained more than one dish, so a single total would make correction difficult. The festival bowl was worse: even I could not confidently identify everything in it from the image alone.
A useful estimator had to do more than return a number. It had to expose what the number depended on.
Every Number Became A Range
The response format now requires calorie and macronutrient ranges rather than false precision. It also asks the model for confidence, unseen factors, grouped dishes, plausible alternatives, and a short set of questions that could materially tighten the estimate.
Image quality can cap confidence. An ambiguous food can remain ambiguous. Multiple dishes stay separate so one correction does not require rebuilding the whole meal.
Most importantly, the model is allowed to say that it does not know.
That is not a fallback message added after the interesting work. It is part of the feature’s successful output.
Corrections Are The Product
I then supplied the missing facts: turkey rather than beef, a particular kind of tortilla, a vegan bowl. Small verbal corrections moved some estimates by hundreds of calories.
That result did not prove the model was useless. It clarified its job.
The photograph creates a rough first pass. The application asks only for the hidden facts with enough leverage to matter. The user answers from knowledge the camera cannot possess. The system returns a tighter operational estimate that remains editable before it enters the diary.
The product is not camera to truth. It is camera to estimate, estimate to useful questions, and answers to a better estimate.
The Provider Is Not The Feature
I also kept the model behind a configurable provider boundary. A free model was enough to prove the request and response pipeline. A stronger model can replace it later without changing the diary or the structure of an estimate.
That matters because model availability, cost, and quality move faster than the rest of the application. The durable work is the contract: ranges, uncertainty, correction prompts, and the rule that no estimate silently becomes verified nutrition data.
The four test photographs did more for the design than a large set of ideal food images would have. They forced the estimator to encounter hidden ingredients, uncertain scale, multiple dishes, and genuine ambiguity before a user could mistake polish for knowledge.
Sometimes the best way to design an AI feature is to begin with the examples that should make it uncomfortable.