Odoo + computer vision in restaurants: the Dodo Pizza case for LATAM

Every Saturday: 287,000 events. Each one is telemetry

Saturday, 9:14 PM in Lima. The Dodo Pizza store in Miraflores takes an order. Eleven milliseconds later, an order.created event lands in Kafka. Eighty-four seconds later, the kitchen tablet tells the pizza maker: "A wave of 12 orders hits in 8 minutes — start stretching dough now." At 9:39 PM the driver shuts the car door with the pizza inside, and the delivery_time metric on the COO's dashboard in Mexico City updates in real time.

This is not science fiction or a TED talk. It is the infrastructure Dodo Pizza has been building since 2018 — the same infrastructure that let the chain grow from 64 to 100+ locations in LATAM without expanding the regional team. Each store generates around 287,000 events on a peak Saturday. Each event passes through computer vision, a stream processor, and Odoo billing in under 100 ms.

If you run a QSR chain in Peru, Mexico, Colombia, or Chile and learn about a failed Saturday from Excel on Monday morning — you do not have an operating system. You have an archive. That archive costs you 8-15% of margin every month: overcooked orders, switching between unsynchronized POS terminals, packing errors, paying drivers during slow hours.

What follows is the concrete technical breakdown: how to wire Odoo POS Restaurant to a computer-vision stack, which modules you need, what hardware to buy, when the pilot pays back in six months, and when it never will. The teardown leans on Dodo Pizza's public materials (including the open-source Dodo IS repositories) plus the parallel experience of Domino's with DOM Pizza Checker.

One-minute summary

01. Computer vision in QSR has been a mature practice since 2019. Domino's (DOM Pizza Checker), Dodo Pizza (Dodo IS), Wendy's, and Taco Bell each run their own stack.

02. Odoo on its own does not do CV. The pairing: point_of_sale + pos_restaurant + iot + a custom bridge module to MQTT/Kafka + edge inference on NVIDIA Jetson (or cloud — AWS Rekognition / Vertex AI).

03. A 3-5 location pilot: USD 28,000-USD 60,000 over 12 weeks. Payback in 6-10 months when cook-time drops 15-20% and refunds drop 25-30%.

04. Not for everyone. Minimum threshold: 5 locations or USD 2M annual revenue. Below that, CV does not pay for itself.

05. The most frequent failure mode is starting with a C-level dashboard. Real adoption comes from a kitchen tablet with under-200-ms latency.

Where the trend came from: CV in restaurants 2019-2026

Computer vision in QSR did not appear yesterday. The timeline of the key milestones:

#1. 2019 — Domino's launches DOM Pizza Checker

Domino's puts DOM Pizza Checker into production in Australia. A CV model running on an iOS device inspects every pizza before it goes into the oven: are the toppings distributed correctly, is the shape right, are all the ingredients present. Stores below 80% "correct pizzas" must remake the order.

#2. 2020 — Dodo Pizza scales Dodo IS across 13 countries

Fyodor Ovchinnikov's chain operates an open IT platform that runs the entire cycle from order to handoff. CV models check dough shape, cheese quantity, and bake time. Events get published to a public "online showcase" — anyone can see how many pizzas a given store produced today.

#3. 2021 — edge hardware gets cheap

NVIDIA ships the Jetson Nano for USD 99, ONNX Runtime gains Raspberry Pi 4 support, and AWS Rekognition Custom Labels prices at USD 1 per 1,000 requests. The barrier to entry for CV in QSR drops an order of magnitude.

#4. 2022 — robotic kitchens

Chipotle and Sweetgreen pilot robotic kitchens. CV is used not for quality control but to coordinate the robot assembling bowls. Accuracy hits 96%+ on standardized recipes.

#5. 2023 — voice AI dies, CV keeps going

McDonald's shuts down the IBM voice-AI pilot in drive-thru — the voice assistant could not handle accents or background noise. But CV for counting cars in line and predicting kitchen load remains mainstream, deployed across 1,500+ Wendy's and Taco Bell locations.

#6. 2024 — Odoo 18 brings an upgraded POS Restaurant

October 2024. The upgraded POS Restaurant arrives with automatic kitchen-ticket generation, and the new Odoo IoT Box ships with native MQTT 5.0 support. The first release where wiring Odoo to a streaming CV pipeline stops being an epic.

#7. 2025 — foundation models for CV explode

YOLOv11 (Ultralytics), Segment Anything 2 (Meta), Florence-2 (Microsoft). Fine-tuning on a specific menu now needs 200-500 labeled images instead of 5,000. Time-to-production drops from three months to three weeks.

#8. 2026 — Odoo 19 announces native Kafka connector

Expected October 2026. It will close the main bottleneck for real-time stacks — for now we paper over it with a custom pos_event_publisher module.

Technical requirements: how to wire Odoo to computer vision

The architecture splits into four layers. Each in turn.

#1. Capturing events inside Odoo

Core modules:

• point_of_sale (community and enterprise) — the POS itself
• pos_restaurant (enterprise or OCA fork) — restaurant extension: tables, split bills, kitchen displays. Feature breakdown on the official Odoo Restaurants page.
• iot (enterprise or OCA iot) — to wire the IoT Box to scales, thermometers, and BLE tray tags.
• stock + mrp (optional) — if you need to trace "cheese → pizza → customer" in a single flow.

What core does not give you:

• pos_event_publisher — a custom bridge module. Listens to pos.order hooks and publishes JSON to an MQTT broker or Kafka. ~200 lines: an Odoo automated action plus Python with paho-mqtt or confluent-kafka.

OCA modules like pos_kitchen_screen solve part of the problem, but most teams write their own event publisher — event schemas are too business-specific.

#2. CV inference

Edge or cloud. For LATAM, I recommend edge.

Edge (NVIDIA Jetson + camera):

• Hardware: Jetson Nano 8GB (~USD 249) or Orin Nano 8GB (~USD 499). Sony IMX477 camera (~USD 75). A passively cooled enclosure is mandatory — kitchens run hot.
• Model: YOLOv8n / YOLOv11n (Ultralytics, AGPL — commercial use requires the Enterprise license starting at USD 2,500/year). Alternatives: RT-DETR or MobileNet-SSD under Apache 2.0.
• Runtime: ONNX Runtime or TensorRT. Latency 40-80 ms per 720p frame.
• What we recognize: correct topping distribution, dough shape, ingredients on the prep tray, packaging integrity.

Cloud (for pilots / low volume):

• AWS Rekognition Custom Labels — USD 1 per 1,000 requests, 300-600 ms latency from LATAM
• GCP Vertex AI Vision — comparable, better latency out of São Paulo (~150 ms)
• Azure Custom Vision — free tier up to 5,000 requests/month

Cloud-only is not a path I recommend: if the internet drops, operations stop. In LATAM that happens more often than you would like.

#3. Streaming

Events have to reach Odoo and the dashboards in real time.

Light stack (3-10 locations):

• MQTT broker (Eclipse Mosquitto, free) — handles 10k+ msg/sec on a USD 20 VPS
• Telegraf + InfluxDB for time-series aggregation
• Grafana for dashboards

Heavy stack (50+ locations, Dodo-scale):

• Apache Kafka (Confluent Cloud / Redpanda / self-hosted) — guaranteed delivery, replay, partitioning
• Apache Spark Structured Streaming or Apache Flink — for windowed aggregations
• Delta Lake or Apache Iceberg — long-term raw-event storage
• Databricks or Snowflake — if you need a managed warehouse

Between Odoo and Kafka: either Kafka Connect or your own microservice (FastAPI + confluent-kafka).

#4. Consumption surfaces

The same events feed different UIs:

• Kitchen tablet — React/Vue PWA over WebSocket. Shows the current queue, the wave forecast 8 minutes out, CV check failures.
• Slack / Telegram alerts — webhook via Odoo Studio or a Flask microservice. Triggers: stock-out, cook-time overrun, CV rejected three pizzas in a row.
• C-level mobile app — React Native / Flutter. Network-wide rollups, top-3 alerts, drill-down to a single store.
• BI dashboard — Apache Superset or Metabase plugged into Iceberg/Delta Lake.

Minimum pilot cost (3 locations)

That is the concrete pricing for a LATAM mid-market chain. Large networks invest 3-10x more.

When the CV stack works — and when it does not

#1. QSR chain with 5+ locations and a homogeneous menu

A standardized product is the load-bearing condition. The model separates a "correct Margherita" from an "incorrect" one with 95%+ accuracy on 500-1,000 labeled samples. A menu with 200 SKUs needs an order of magnitude more data and constant retraining.

Anonymous case: a burger chain in Lima, 7 locations, USD 3.5M annual revenue. CV checks of the build before packaging cut refunds via UberEats and Rappi by 28% in 4 months. Pilot ROI on 2 stores: 7 months.

#2. Cloud kitchen / dark kitchen with high delivery share

Dark kitchens have no dine-in but plenty of order batching. CV identifies which burger goes in which bag (via QR stickers), wiping out packing errors. This is critical in Mexico and Brazil, where cloud-kitchen operators (CloudKitchens, Foodology) run 10-20 virtual brands out of one kitchen.

#3. Chain with a regulated cooking process

If you have a formalized SOP — "pizza cook time 8 min ± 30 sec," "ham portion 80 g ± 5 g" — CV gives you automated compliance enforcement. The alternative is a quarterly manual audit that misses 95% of deviations.

Works with tweaks

#4. Highly customized menu (à la carte sushi, fine dining)

CV needs either constant retraining (expensive) or a simpler architecture — for example, not "right dish" but "weight matches the order" via scale integration through Odoo IoT. It works, but the impact is modest: portion control, not quality.

#5. Regions with unreliable internet

If average latency is > 100 ms or the internet drops > 1% of the time, cloud CV is out. Edge inference becomes mandatory. CAPEX goes up; opex and risk go down.

Does not work

#6. 1-3 locations, < USD 500k annual revenue

USD 28-32k TCO does not amortize. Better to spend the budget on a clean Odoo POS without CV, SOP standardization, and crew training.

#7. Team with no data-engineering bench

CV models are not "set and forget." Within 3-6 months the model drifts: lighting changes, the ingredient supplier changes, the pizza maker's hand-style changes. Without an MLOps cycle, the model starts throwing false positives and the team stops trusting it.

#8. Family business with no formal processes

If the recipe is "by eye, like grandma did it," CV verification is meaningless. Formalize the process first; automate after.

5 common mistakes during rollout

#1. Starting with the C-level dashboard, not the kitchen tablet

The Dodo Pizza team wrote it explicitly in their lessons learned: "We built for the board first because they sign the contract. Mistake. Real adoption took off when we rebuilt the kitchen tablet from scratch." If the line cook doesn't see value in the first week, the system never sticks.

What to do: first MVP = tablet with one feature (8-minute wave forecast). The COO dashboard comes after 80% of cooks use the tablet daily.

#2. Cloud-only CV with no edge fallback

When internet drops, ops freeze. In LATAM the commercial-internet average uptime sits at 99.5-99.8%. Across 100 stores that means 1-3 stores hit problems every day.

What to do: edge inference plus asynchronous cloud enrichment. Local Mosquitto queue plus persistent storage to survive disconnects.

#3. Cutting corners on data labeling

Cheap labeling (unprepared in-house team) yields a 60-70% accurate classifier. The cook watches the system get it wrong one out of three times and stops trusting it in a week.

What to do: outsource to Scale AI, Labelbox, or Sama (from USD 0.05 per image). At least 1,000 examples per class, ideally 3,000-5,000. Inter-annotator agreement ≥ 90%.

#4. "Ship the model and forget it"

Three months in, lighting changes, suppliers change, the menu shifts — the model drifts. Accuracy slips from 95% to 75% silently, because nobody monitors.

What to do: MLOps from day one. Precision / recall metrics piped into Grafana. Alerts when either drops below threshold. Quarterly retraining or whenever the menu shifts meaningfully.

#5. Ignoring per-country differences (PE vs MX vs BR vs CO)

A model trained on Mexican pizzas with queso Oaxaca will not work in Brazil with mozzarella. Differences in color, texture, and dough thickness are decisive.

What to do: either a separate model per country or a multi-class model with locale as a feature. Account for differences in plating, packaging, and lighting.

Case study: Dodo Pizza in LATAM

Public information about Dodo Pizza's tech stack in LATAM:

Context. Chain founded in Syktyvkar, Russia, in 2011. By 2026: 1,100+ locations across 14 countries, 100+ of them in LATAM (32 in Peru, 38 in Brazil, 18 in Mexico, 14 in Colombia — per company filings).

Stack. Dodo IS is the in-house chain-management platform. Parts of it are open-sourced on Dodo Pizza's GitHub. It covers POS, CRM, marketing, analytics, inventory, and CV checks. Stack:.NET Core, PostgreSQL, Kafka, ClickHouse, ML models on PyTorch.

CV applications (per the Dodo tech team's HighLoad++ and Saint HighLoad talks):

1. Pizza quality control before baking — correct topping distribution, shape.
2. Tray detection and batch formation for drivers.
3. Dining-room headcount to forecast kitchen load over the next 30 minutes.

Company-reported results (from technical publications):

• −27% average cook time vs baseline over 12 months
• +19 points delivery NPS
• 99.97% rolling 12-month pipeline uptime
• Peak throughput: 10,000 events/minute (Saturday, 8 PM Lima)

We built Dodo IS as a product, not as an internal system. That is why we can open-source the code.

What matters for other chains: Dodo Pizza started investing in IT as a product when it had 10 stores. That allowed it to scale without a linear IT team. Chains that defer the investment until 50+ stores typically hit an operational ceiling: further growth requires a full rewrite of the systems.

Checklist: is your chain CV-ready?

If you answer "yes" to 6 or more of the 8 items, a CV pilot has a reasonable shot at paying back:

1. I run ≥ 5 locations or ≥ USD 2M in annual revenue
2. The menu is standardized (≤ 30 SKUs)
3. Formalized cooking SOPs exist
4. I am willing to invest USD 25k-60k in a 3-store pilot
5. I have an IT team or a partner with Odoo + Python experience
6. I am willing to reshape kitchen processes for a data-driven approach
7. I can fund the post-pilot MLOps cycle (≥ USD 500/month)
8. I understand payback runs 6-10 months, not 6 weeks

Download the full checklist (PDF) + pilot RFP template →

Conclusion: the window closes between 2027 and 2028

Computer vision + Odoo is not a silver bullet. It is a tool for chains with 5+ locations, a standardized menu, and a real willingness to operate data-driven. If you fit the profile, the LATAM competitive-advantage window closes over the next 12-24 months. After 2027-2028, this becomes a baseline requirement, the same as online registers and UberEats integration.

Ready to talk it through? Book a 30-minute call. No long forms, Calendly direct.

Going deeper:

• Computer Vision for restaurants — Tier B pillar with extended technical breakdown
• Odoo POS Restaurant: modules and configuration — Odoo stack deep dive
• Odoo in Peru, Odoo in Mexico, Odoo in Colombia, Odoo in Argentina — country pillars
• Odoo implementation and Odoo audit — service pillars
• Dodo Pizza case: full architecture — original case study
• Real-time Kafka pipelines — Tier B angle

Frequently Asked Questions