What If the Debrief Is the Product?
How an idea for an AI cooking coach turned into a tool that explains why batches fail.
I cook a lot, and I spend my working days building reports that explain why a production line hit or missed its numbers. At some point those two things ran into each other. If a factory can get a breakdown of why a shift went badly, why can’t a kitchen?
So I started looking into an AI cooking coach. The first version in my head was the obvious one: a camera over the stove, a probe in the pot, and a voice that tells you when to stir. This post is about why I moved away from that, and what I’m working on instead.
The Live Coach Is the Hard Part
Real-time coaching sounds great and is very hard to get right. The model has to recognise what you’re doing, from any angle, in bad light, fast enough to matter. Get it wrong once and you stop trusting it.
The part after the cook is different. Once a batch is done you have the probe log, the step times and the recipe. Nothing is time-critical. And the useful question isn’t “what happened in this batch?” but “why do batches like this keep going wrong?” That’s a data question, which is the kind I already know how to answer.
That became the working name: Process Debrief. The debrief is the product.
Checking Whether Anyone Would Pay
Before building anything I wanted to know who has this problem badly enough to pay for a fix. I split the market into 12 segments, from home cooks to commissary kitchens to craft breweries, and researched each one. Then a second pass went after every claim: refute it, correct the numbers, find the competitors the first pass missed.
47 ideas went in. The survivors were scored on six things: how painful the problem is, willingness to pay, market size, how open the field is, how well it fits what I can build, and how fast it could earn anything.
Two things stood out:
- Consumers are a tough sell. People like cooking gadgets, but few pay for a report about their dinner.
- Commercial kitchens already have a rule to measure against. Cooked food has to cool from 135°F to 70°F within 2 hours, and to 41°F within 6 hours. Kitchens already log this. Most of those logs get filed and never looked at again.
The Cooling Debrief
So the first real demo is a cooling-log debrief for a commercial kitchen. It’s built on generated data for a fictional commissary, with problems planted on purpose (a pan that’s too deep, a cook who skips a step, a walk-in that runs warm on certain afternoons) plus some random bad luck.
The page scores every batch against the cooling rules, then asks why the failures happened. A few choices I’m happy with:
- A batch only passes or fails when a reading proves it. If a gap in the log hides the answer, the batch is marked unverifiable rather than guessed.
- Causes aren’t violations. A tight lid or a deep pan is a reason a batch cooled slowly, not a rule broken.
- You can hold out the other causes. When you look at pan depth, you can remove batches that failed for something else, so one problem doesn’t hide behind another.
What I Don’t Know Yet
The big open question is whether someone who runs a kitchen can open the page cold and find the problems in ten minutes. I built it, so I can’t test that on myself. That’s the next step.
The demos are still drafts. You can find them, with the caveats, on the project page.