Carta

Carta turns the restaurant QR menu into an interactive, social experience. Diners scan the QR code on their table — no app, no sign-up — and see every dish in 3D on the table with augmented reality. Everyone at the table builds an order together, and the check gets paid without waiting for the bill. For restaurants, Carta is an operating system for the floor: live orders, a waiter app, a captain view and an analytics back-office.

Status (November 2026): v1 is being built. Phase 0 (foundations) is done except the first live deploy: the API, database schema, test suite, CI and the portable Docker image are in place, and the Railway deployment is ready to switch on (deploy/README.md). v1 drops AR/3D, payments and diner accounts (see docs/plan/); the sections below describe the original MVP vision. See Project status.

Watch the launch film

A 25-second film in two cuts: 16:9 for YouTube and LinkedIn and 9:16 for Reels and TikTok. The source and credits are in marketing/video/.

The problem

Menus went digital, but the experience never changed. The QR code on the table still opens a static PDF: long lists of options, no picture of the actual dish, no sense of portion size and no way to filter for allergies or diets. Friends pass one phone around to decide, and the restaurant learns nothing from any of it.

Digitizing the menu didn't add value — it only changed the format.

How it works

Three layers of adoption

Each layer removes a barrier before asking for anything:

Layer	For	What it adds
0 · Anonymous	Anyone who scans the QR	A visual menu with 3D/AR previews, allergens and the chef's top 3. Zero friction.
1 · Free account	Diners at a shared table	A one-tap Google/Apple login that joins the table session: friends share dishes, each person keeps their own order, the waiter is called when everyone is ready, and past visits are saved.
2 · Carta+ (MXN $29/month)	Regulars	AI recommendations, smart dietary filtering, cross-restaurant memory, priority reservations and no ads. Part of each subscription funds meals through partner NGOs.

The diner app

For the restaurant

Waiters own a portable professional profile: their ratings, reviews and experience travel with them from restaurant to restaurant, much like an Airbnb host's. Captains run the floor, the crew and device access. Owners manage everything from the back-office:

Design system

The creative north star is "The Digital Sommelier": the warmth of a fine-dining room with the precision of augmented reality. Cream surfaces, wine-red actions and gold accents, set in DM Serif Display and DM Sans. The full specification is in docs/Carta_Design_System.md. The 27 Google Stitch mockups and the 35-screen interactive prototype both live in this repo, and you can try the prototype live.

Architecture (MVP)

v1 differs from this MVP sketch: one Docker image (FastAPI serving the PWA) on Railway with PostgreSQL 16, Cloudflare in front and R2 for photos and backups; no Redis, no AR/3D, no payments. See docs/plan/02_Arquitectura_v1.md and ADR-015. The Cloud Run design below is kept for stage 2 in deploy/etapa2-gcp/.

The MVP is deliberately simple: one deployable API, a PWA that needs no install, and a 3D pipeline that never publishes without a human in the loop.

flowchart LR
  subgraph Clients
    PWA["Diner PWA<br/>model-viewer AR"]
    Floor["Floor view<br/>waiter tablet"]
    BO["Back-office<br/>web"]
  end
  API["Carta API<br/>FastAPI · async SQLAlchemy<br/>Cloud Run"]
  PG[("PostgreSQL 15<br/>Cloud SQL")]
  Redis[("Redis 7<br/>Memorystore")]
  GCS[("Cloud Storage + CDN<br/>photos · GLB / USDZ models")]
  Queue[("3D job queue<br/>Postgres table")]
  Worker["3D worker<br/>local image-to-3D model"]
  Auth["Firebase Auth<br/>optional login"]

  PWA -->|HTTPS JSON| API
  Floor -->|HTTPS JSON| API
  BO -->|"HTTPS JSON · approves 3D models"| API
  API --> PG
  API -->|cache · rate limit| Redis
  API --> GCS
  API -->|verifies token| Auth
  API -->|enqueues| Queue
  Worker -->|takes jobs| Queue
  Worker -->|draft models| GCS
  PWA -->|3D assets| GCS

Key decisions, each one documented as an architecture decision record:

Decision	Why
Modular monolith on Cloud Run	Ten pilot restaurants don't justify running many services; the package boundaries allow splitting later.
PWA for diners, not a native app	Nobody installs a 40 MB app to read a menu. AR runs through <model-viewer>, which hands off to Scene Viewer on Android and AR Quick Look on iOS.
Signed guest token, no account	Layer 0 must be frictionless; login is optional and comes later.
Polling with ETag every 3 s instead of WebSockets	Stateless, no sticky sessions, and it works on poor networks.
Local 3D generation plus human review	Keeps quality and cost under control. The design enforces this with a database constraint, so a model nobody approved can't be published.
GLB + USDZ with a weight budget	The minimum needed to cover native AR on both Android and iOS.

Stack: Python 3.11 · FastAPI · SQLAlchemy 2 (async) · Alembic · PostgreSQL 15 · Redis 7 · Firebase Auth · Google Cloud (Cloud Run, Cloud SQL, Memorystore, Cloud Storage) · Terraform · GitHub Actions · PWA with <model-viewer>.

This is the beginning of the README. Read the rest at the original. Read the full README ↗