The problem
Long cooks create lots of data but still leave the cook answering practical questions: Is the pit cooling off? Is the meat entering a stall? Am I likely to finish on time? What happened the last time I cooked this cut?
The product shape
The application stays client-side instead of introducing accounts and a backend that the use case does not require. It combines active-cook monitoring with history and analytics, while keeping the data portable.
- Live ThermoWorks RFX data arrives through MQTT over WebSocket.
- Target and low-pit alarms surface actionable conditions instead of just drawing graphs.
- Stall detection and finish-time estimates turn telemetry into decisions.
- Cook history, comparisons, recipes, and JSON backup make the data useful after the cook ends.
- PWA and accessibility work keep the product usable on the devices and in the situations where it actually gets used.
An intentional non-decision
There is no backend simply because “real apps have backends.” Local storage, export/import, and direct device integration satisfy the current operating model with less infrastructure, less account friction, and fewer failure modes.
What this demonstrates
PitLogic is useful portfolio evidence because the product is not about AI infrastructure. It shows end-to-end product decisions around live data, alarms, forecasting, accessibility, testing, deployment, and the discipline to stop before unnecessary platform work takes over.