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?
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.
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!
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.