Chef Canon · compiled Aug 16, 2026
Kostia Shinderman's notes on Chef Canon (his Miro letter, the 16 pinned comments, and his texted strategy summary) with Ernie's responses beside each one. All 17 responses were posted to the Miro board on Aug 16.
All 17 replies posted to the board Aug 16The long "General comments" note on the Miro canvas, Jul 28. Warm opener: great POC, genuinely impressive progress, and he calls the positioning strong: "Meez has your recipes. Chef Canon has the recipes you wish you had."
One reply, pinned near his letter.
Read every word. This is exactly the outside pressure this needed. Quick reactions: the 3-pillar frame is right, the focus critique is fair (the dashboard is demo theater today), and the commercial questions in your pack are the right ones to settle before we spend another dollar on build. None of this lands cold. Let's walk through it live.
Kostia's condensed summary, texted Aug 12.
1. Start with Chef Canon: an awesome way to drive brand, reach and credibility with top-tier restaurants. Possibly put more focus on operational efficiency for premium cuisine outlets. Think "Cuisine OS": delivers quality and operational efficiency. Might hit a TAM wall, but that's OK; the AI will learn and optimise from tier-1 operators.
2. Then extend into "Growth": once brand, recognition and trust are established, leverage the Dishtories concept to turn recipe data into a B2C model for restaurants: loyalty, sharing, and a much wider TAM, with 200M+ diners annually at high-end restaurants.
"…the above might pivot completely once it starts, as most startups do :) but the core of the solution is using the recipe as the data model/spine that drives new AI solutions for restaurants and diners."
Follow-on after Ernie raised the 200-recipe data-control cap: "That makes sense… also makes more emphasis to extend the OS modelling capabilities as the key value-add (ingredient pricing, labour costs, optimal food-waste modelling) balanced with ultra-high-quality recipes. Assume they add their own recipes so the AI can optimise around their BAU model."
Sixteen comments, sixteen responses
All pinned by Kostia on the "As Built Model" frame, Jul 28, 10:05pm to 11:42pm PT. Each card pairs his note with Ernie's potential response.
Current recipes do not include time taken, perishability or costs. He AI-modeled some and wants accuracy tested.
Agreed, and good news: about 81% of the 34,500 ingredient lines are already normalized to grams, which is the foundation costing needs. The inventory tool on the site already goes from a supplier list to ingredient matching to cost per plate. Time and shelf life are the open pieces. Let's pick 10 recipes and benchmark AI estimates against Martin's real numbers to see where accuracy lands.
Recipes also live on Yelp and Google with customer photos. How might we leverage that?
The onboarding audit already scrapes the restaurant's site. A Google Places integration is wired in code but switched off right now (billing toggle). Yelp reviews and top menu items would ride that same enrichment path, so this is very doable.
Likes the Chef Canon name, but is it still representative if we move to an Agentic Cuisine Director model?
Name isn't locked yet; there's a whole naming and trademark research page on the prototype. I think of it as two layers: the vault is the credibility anchor, the agent is the product arc. Happy to pressure-test names against that framing.
If restaurants upload recipes and the platform learns from them, there's an AI copyright consideration.
Real issue and worth getting on paper before any beta. Current stance: contributor brands stay anonymous to customers, and customer uploads stay private to their account, no training on them by default. Let's write the data position down together.
From Library to Agentic Cuisine Director.
That's the arc exactly. Library earns the trust; the agent keeps them paying every month.
Phase 1: what problem are we solving? Inspiration? Menu quality?
Martin's framing from our calls: eliminate the chef's writer's block with proven, ready-made ideas. Quality plus margin, aimed at casual and fast-casual first, where the owner often isn't a chef. Spend more time making money, less time figuring it out.
Lead with the value, not Martin. Risk of using Martin too much. It's like having Martin at your restaurant, not just the recipes.
Fully agree, and that's the tagline we've been building around: you run the kitchen, we run the rest. Martin is the trust layer, not the product. The "having Martin in your restaurant" line is better than anything we've written. Stealing it.
Use the same AI smarts on ANY uploaded recipe. Huge day-1 value for signups.
Yes. Recipe upload with AI standardization is already on the roadmap, and the ingest pipeline that standardized Martin's 3,018 recipes is reusable for customer uploads. "Get Martin's recipes, plus superpowers on your own" is the right day-1 pitch.
100 recipes might not be enough, but an AI engine converting any recipe to cost per plate plus market costs is huge value day 1, and friendly pilots improve the model.
Agreed. Plan has been a closed beta with 5-10 operators Martin trusts, feedback as the price of entry, and those pilots are exactly who trains the cost model into something defensible.
Nervous about the paid catalogue model: copyright and ownership. Maybe the network shares a few recipes free to support local restaurants instead.
Worth a real debate on the call. Two thoughts: Martin's archive is licensed from him directly and served anonymized, so the copyright surface is narrower than it first looks. And the free community angle doesn't have to replace the vault; it could be the top of funnel while the paid vault and the agent stay the premium layer. Let's whiteboard both models side by side.
A lot of this can and should be phase 1: live pricing APIs plus AI to convert per plate.
Mostly agree. V1 costing works off the restaurant's own supplier list, which they can paste or upload today. Live supplier price feeds are the upgrade path once we know which suppliers the pilots actually use.
40k top-tier restaurants. Do we sell to chefs or restaurants?
Restaurants. Pricing is per concept per location, not per seat or per recipe, and the chef is the champion inside the account. Same conclusion you reached: the restaurant owns the systems and the budget.
Turn this into direct outbound: pregenerate the dashboard, send it, they claim it. Also warns audit scope beyond recipes gets complex, and suggests a social scan plus nearby-restaurant comparison.
Love this one. I already run an outbound engine on another project that pregenerates personalized audits and pages at scale, so "here's your dashboard, claim it" outbound is close to zero new infrastructure for us. And agreed on scope: the audit should read as recipe and operations insight, not a promise to replace their POS. The social and nearby-competitor scan fits the same scrape pipeline.
Super rich in features but missing the core IP: recipe quality, recommendations, the AI Cuisine Director. Simplify the dashboard to 3 insights: Quality, Cost, Growth.
Fair hit. The dashboard today is a pitch demo running sample data, and it drifted toward restaurant-OS theater. Your 3-insight frame (Quality, Cost, Growth) matches where this should land. I'll mock a simplified version around those three and we can react to it.
Tried a recipe in AI: local ingredient prices, operational cost, shelf life. If it works on the 3,000-recipe base we can teach AI to interpret any recipe. Massive value to planning.
This is the plan, and the corpus is ready for it: 2,944 of the 3,018 recipes are machine-readable and gram-normalized. The move is to benchmark AI cost and shelf-life estimates against Martin's known numbers first, so the engine has a validated baseline before we point it at stranger recipes.
Built a POC: recipe to costs and time, AI suggestions to reduce cost, and a quality indicator tracking changes against the original recipe.
This is great, and the quality indicator tracking drift against the original recipe is a genuinely good mechanic. Want to walk me through it? I'll bring the costing flow from the site and we can merge the best of both into one spec.