Fooodo / Docs

Architecture

How UVS sits at the centre, what each module does, and the contract between them.

Fooodo is not a single product — it is an operating layer that the modules plug into. The page everyone calls "the Fooodo dashboard" is actually three or four separate modules sharing one record. This page is the conceptual map.

UVS — the operating core

UVS (the order / operations management system) is the central nervous system. Everything written by the platform — orders, payments, table state, kitchen tickets, reservations, inventory deltas — lives in UVS first, and modules read from there.

That means:

  • Modules don't talk to each other directly. The QR menu doesn't call the kitchen module; both write to UVS, and UVS publishes change events.
  • POS integration is a UVS connector, not per-module plumbing. R-Keeper, Toast, iiko, and Square all map to the same internal record. New connectors don't require module changes.
  • Insights reads from UVS, not from individual modules. That's why every recommendation can be traced back to a measurable EBIT driver — the underlying data is one consistent stream.

Modules

A "module" is a UI surface plus its specific business logic. Each one is independently deployable; operators run only the modules they need. The current shipped set:

  • Digital menu (guest-facing)
  • Ordering (guest-facing)
  • Payments (guest-facing)
  • Kitchen flow (operator-facing)
  • Tables / floor map (operator-facing)
  • Tips & bill split (guest-facing)
  • Reviews (operator-facing)
  • Reports (operator-facing)
  • Insights (chain-level)

The Insights module is structurally different from the others: it consumes UVS read-only and produces recommendations rather than transactional state. That's why it has a separate approval queue and why GDPR Article 22 enforcement lives there.

Why this layering matters

Operators ask, regularly, why we don't ship a "QR menu plus payments" SKU and call it done. The answer is in the layering: a module-only product can never coordinate the floor. A guest can scan a menu and pay, but a single guest experience touches floor, kitchen, payment, POS, reservation, and reporting — each of those is a separate module. Without UVS in the middle, the modules don't share a record, and the operator ends up reconciling by hand.

The "system of record" framing is the same idea POS vendors use. Fooodo's contribution is making the record visible to the modules that actually run guest-facing service, not just to the back office.

On this page