Built an AI tool that turns fridge photos into dinner menus - 9 lessons
I have always been bad at meal planning. I would buy groceries with good intentions, then forget what I had and order takeout while food rotted in the fridge.
So I built PanSnap: you snap a photo of your fridge and get a complete dinner menu with recipes, a shopping list, and step photos. Launched on Product Hunt last week.
Some lessons from the build:
-
A complete menu is a different product than a recipe. Most AI recipe tools generate one dish. We generate 2-4 that work together and share ingredients. Harder to build, but that is how people actually eat.
-
Photo to ingredients is harder than it looks. Chicken could be raw breast, cooked thigh, or rotisserie, and that changes the recipe. Took weeks of prompt tuning to get the right level of detail.
-
Image generation ate the budget. Even at ten cents an image, a full menu is a few dollars. We moved to slot-based rendering so credits match what is actually produced.
-
Free tier with credits beats subscriptions for food apps. I tested a subscription with beta users. Everyone said they would pay per use, not monthly.
-
Social features were a waste. Built recipe sharing. Nobody used it. People want their own meal plans.
-
The meal planning calendar also failed. Users do not want to plan a week ahead. They want dinner tonight.
-
Language support mattered more than expected. Added Chinese. A meaningful chunk of users are non-English speakers.
-
Async generation needs a safety net. The pipeline is poll-driven on Cloudflare Workers. If someone closes the tab mid-generation, a cron job picks it up every minute.
-
Shipping beats perfecting. The first version had three dishes and no photos. People used it anyway.
Happy to answer anything about the build, the AI pipeline, or the pricing experiments. And I am curious: for anyone selling a consumer AI tool, how are you handling image generation costs?
On your closing question about image costs, the input side has an easy win if you have not taken it yet: downscale before you send. Fridge photos come off phones at enormous resolutions, and vision models do not need anywhere near that to identify ingredients. In my own desktop tool I resize every image so the longest edge is 2048px before it goes to the model, and for text extraction and object-level recognition I have not been able to measure a quality difference, while payload and token cost drop a lot on 4K inputs. Ingredient identification might tolerate even smaller.
The other lesson that jumped out is number 7. Non-English support being unexpectedly valuable matches my experience exactly: each language is less a feature than a separate market, with its own search terms and its own competition, often much thinner competition. If users outside English are converting, it may be worth checking where those users are finding you before spending anything on the crowded English channels.
Have you measured how far down you can push input resolution before ingredient recognition actually degrades, or is the current size still whatever the phone camera happens to produce?
Oh, your perspective is quite interesting. I use the Gemini model to process image inputs, and it usually handles this task extremely well, so I have no concerns about that. I will consider more markets in the future. I conducted some small‑scale research on this project before launching it. I was determined to build it because my mother liked my idea. I will not make it overly complex until the business processes are fully functional.
The move from per-image pricing to slot-based rendering sounds like the right unit for this product, especially when a full menu can cost dollars instead of ten cents. I’d make the credit ledger visible internally at the menu level: ingredient extraction, recipe generation, each photo slot, retries, and abandoned jobs. Since the pipeline is poll-driven, pairing that ledger with a retry/close-tab rate should show whether the expensive failures happen during generation or in the handoff back to the user.
Thanks — the ledger point lands, and it turned out to be sharper than we
expected once we started measuring.
Our pipeline is poll-driven in a fairly literal sense: each read of the task
advances it one bounded step, which keeps generation at zero idle compute on
the Workers free plan. That means closing the tab doesn't just break the
handoff — nobody polls, so the pipeline stops mid-menu and the task sits at
N-1 images.
We do have a cron that picks up abandoned tasks (anything idle for 45s), but
the free-plan ceiling is 50 outbound fetches per invocation, and one render
tick is ~30 (6 slots × create + polls + download). So exactly one task
advances per minute. Ten people abandoning at once is a ten-minute queue.
Which is mostly why your framing caught my attention: the number that matters
isn't image cost, it's cost per completed menu, and the delta between that and
cost per started menu is where the money actually goes. Right now we can see
credits in and out, but not attribution by stage (extraction vs recipe vs each
slot) or the retry/abandon split you're describing.
Two questions if you've built this before:
out to be mostly a rendering-cost problem?
bucket?
The point about shipping early really resonated with me. I also find that users often care more about solving one immediate problem than having a perfect product from day one
Where is the product? I'd love to go over it.
pansnap.app: Register and receive a generous amount of bonus points, enough to complete several tasks. I look forward to hearing from you.
The failed social features and meal calendar are probably my favorite lessons here. Both sound like reasonable features on paper, but users just wanted dinner tonight. Good reminder that making a product “bigger” doesn’t necessarily make it more useful.
That one cost the most to learn. We built both because they looked like
obvious v1 features — every meal-planning app has a weekly calendar, and
sharing feels like free distribution.
The calendar was the clearer miss, and it took me a while to understand why.
Planning a week ahead requires you to already know what you want to eat —
which is the exact problem people came to us with. We were asking them to
solve it themselves first, then use our product to record the answer.
Sharing failed differently: it assumes your menu is something worth showing
someone else. But the job is "what am I eating tonight," not "what should I
post."
Dinner tonight is the only moment where the friction is actually real.
The cost insight is especially useful: logging retries and abandoned generations, not just the happy-path image price, feels like the right unit economics. I also like the “dinner tonight” finding—shipping the narrowest repeatable moment seems to beat adding a bigger planning surface.
"This is the epitome of great building! Taking a real-world, everyday micro-pain and turning it into a functional AI tool is always where the best lessons are learned. Documenting the process into 9 distinct lessons is super valuable for the community. Sometimes the challenges with image parsing and prompting are way harder than people think. Thanks for sharing the insights, looking forward to reading the full breakdown!
Thanks — and you landed on the part that actually ate the calendar: image
parsing.
The hard bit isn't identifying what's there. It's the state. A chicken breast
in a photo could be raw, cooked, or a rotisserie bird from the deli counter,
and those are three different dinners. Eggs are the worst case: "eggs" tells
you almost nothing, because a boiled egg rules out half the menu and a raw one
rules out the other half.
We spent weeks oscillating on the level of detail. Too fine and the model
returns "2 large eggs, in carton, back shelf" — technically accurate, useless
for cooking.
Too coarse and it writes a recipe you can't actually make. What
finally worked was asking for state plus a rough quantity, and explicitly
telling it to stop caring about packaging, brands, and shelf position.
Prompting is a close second. Our first menus came back half Chinese and half
English, because a soft instruction at the top of a long prompt gets ignored by
the time the model reaches field 12. Language rules are now per-field and
marked as hard rules.
The strongest promise here is reducing the “what do I have?” decision, so I’d optimize the first-run experience around time-to-menu rather than number of recipes. Fridge photos will always be incomplete or ambiguous; letting someone correct the detected ingredients and mark allergies or staples could improve trust more than adding another generation feature. A small feedback loop on which suggestions actually get cooked would also make the product smarter over time.
The photo-to-meal workflow is a strong wedge because it starts from a real moment of friction instead of asking users to maintain another pantry database. I’d instrument the first session around three drop-offs: photo quality, confidence in ingredient recognition, and whether the suggested menu actually gets cooked. A “use what I have” mode plus an easy correction loop could turn those misses into better personalization. Product Hunt traffic can be noisy—are you seeing repeat use from the same household after the first novelty meal?
The pricing test is the interesting signal here. Have users actually repeated the pay-per-use flow enough to show that revenue per meal plan covers the image cost, or is repeat purchase behavior still the main unknown?
I’d keep the credit model, but measure it against a successful dinner rather than an image. I would log the cost of each completed menu, including retries and abandoned jobs, then set credits so a new user can get two or three successful outcomes before the paywall. That makes the pricing conversation much clearer than a generic monthly plan.