Eat Assistant

The Market Gap

The Italian HoReCa market runs 330,000 active businesses and sits halfway through a transition it hasn't finished. Forty-five per cent of restaurants have adopted a digital menu of some kind, and nearly all of those turn out to be PDF files behind a QR code. No interaction. No personalisation. No data coming back. Only 12% touch AI at all.

The cost of that is concrete, not theoretical. Upselling rides on staff who are already juggling four tables, so it happens or it doesn't depending on the night. Foreign customers order what they recognise instead of what they'd actually want. And owners shut the door each evening with no idea which dishes earned their keep or which tables fell flat. What the market was missing was a platform that treats the menu as an active sales instrument. That's the gap EatAssistant was built to fill.

The decisions that shaped the product

A handful of choices at the very start set the shape of everything after. Each one cut against the standard startup playbook on purpose.

Zero login for the customer.‍

The usual move is to grab the email and build a CRM asset you can resell later. We went the other way. No registration, no friction, order placed in under a minute. Someone seated and hungry is worth more as a completed order than as a row in a database, and every step between scanning the code and placing the order bleeds conversions. We built the product to delete those steps, not add one.

AI anchored to the live menu graph.

‍A plain off-the-shelf LLM would have shipped faster and cost less. It would also have handed us a trust problem no later feature could patch: in a restaurant, an AI that suggests a dish the kitchen doesn't make breaks the relationship right there at the table. Wiring the intelligence into real menu data, live, cost more engineering and was clearly the right spend. The AI can only suggest what actually exists, at the current price, with allergen data that's correct. That limit is the whole differentiator.

Direct payments via Stripe Connect.‍

A marketplace escrow model would have given us more leverage and tidier cash management. It also parks the restaurateur's money with us as the middleman, gums up their accounting, and quietly erodes trust, which is fatal in a B2B SaaS where retention is a feeling that accrues over months. The direct flow trades away platform control for operator trust. Operator trust is the retention moat, so that's the trade we took.

Architecture and analytics fell straight out of those three calls. Five applications for five distinct users, all sharing one data layer, so every interaction from QR scan to suggestion accepted to payment stays measurable and queryable.

The System

EatAssistant runs as five independent interfaces on a single backend that ties together every data point across the customer journey.

• Customer Menu App: Angular 19, RxJS, ngx-translate. Zero login, zero download. Opens on scan, supports 10+ languages through the DeepL API, and handles browsing, AI chat, ordering, and payment confirmation inside one browser session.

• AI Chat Layer: OpenAI API and Mistral AI, connected to the live menu data graph. Responds only with real menu items, at current prices, with live allergen data. Tracks per-session metrics: language, device, response quality, and suggestion acceptance rate.

• Restaurateur CRM: React, Next.js, shadcn/ui, Tailwind CSS. A full management console for menu, pricing, tables, orders, payments, and team permissions, with role-based access for Owner, Manager, and Staff, plus support for multi-venue operators.

• Admin Panel: Internal dashboard for platform-level monitoring, business analytics, plan management, and commercial oversight.

• Marketing Landing Page: React 18, Vite, TanStack Query. A conversion-optimised acquisition page, built and iterated in-house. Google CPC traffic sent here converts at 25.3%.

• Backend API: NestJS (TypeScript), Passport.js with JWT authentication, dual-database architecture (MongoDB via Mongoose and PostgreSQL via TypeORM), AWS S3 for storage, Stripe Connect for subscriptions and direct payouts to restaurateurs.
• Infrastructure: Docker Compose, monorepo with git submodule architecture.
• Analytics Layer: Full-funnel tracking from QR scan to completed order, filterable by table, time window, product category, and device, with a native A/B testing framework for menu variants and messaging.

• Smart QR System: Two levels. One QR per restaurant for marketing campaigns, with UTM tracking and A/B test assignment. One unique QR per table, with a session token and direct kitchen routing.