CAPY — Sistema de Pedidos para Restaurante/Club (MVP)
Sistema web para que clientes vean la carta, hagan su pedido sin necesidad
de crear cuenta, indiquen su ubicación (mesa o sector general) y paguen
desde el celular. El staff (camareros y cajero/admin) ve los pedidos en un
tablero en tiempo real, cambia su estado y tiene un historial completo de
operaciones.
No reemplaza ni se integra con el sistema de gestión del restaurante.
Es un sistema independiente para tomar y pagar pedidos.
Stack
- Frontend: React + Vite + Tailwind CSS
- Backend / Base de datos / Tiempo real: Supabase (Postgres)
- Pagos: sin pasarela externa por ahora (ver sección de pagos abajo)
- Hosting: Vercel (o cualquier hosting de sitios estáticos)
Cómo se identifica cada tipo de usuario
Este sistema tiene dos identidades completamente separadas:
Cliente (sin login) — la primera vez que alguien pide algo, se le pide
nombre y WhatsApp (sin contraseña). Ese dato se guarda en su dispositivo
(localStorage) junto con un token secreto, así en visitas siguientes
desde el mismo celular no se le vuelve a preguntar y puede ver sus pedidos
anteriores. El WhatsApp le sirve al mozo/cajero para contactarlo si no lo
encuentra en el sector, o si necesita avisarle algo (ej. un producto que
se agotó). No hay verificación real del número — cualquiera puede escribir
cualquier WhatsApp. Es aceptable para el objetivo operativo de este MVP
(poder contactar a alguien en el lugar), pero no es identidad verificada.
Staff (con login real) — camareros y cajero/admin entran con email y
contraseña por /admin/login, usando autenticación real de Supabase. Hay
dos roles:
camarero: ve el tablero de pedidos, cambia estados, contacta al
cliente por WhatsApp si hace falta. No edita la carta.admin: todo lo de camarero, más gestión de carta/precios/sectores,
confirmación de pagos (comprobantes y cobros en persona), e historial.
Estructura del proyecto
restaurant-app/
├── src/
│ ├── pages/client/ # Pantallas del cliente (identificación, carta, ubicación, pago, estado)
│ ├── pages/admin/ # Pantallas del staff (tablero, historial, editor de carta)
│ ├── hooks/ # useAuth (staff), useCustomer (cliente), useCart, useOrderPolling
│ ├── lib/ # dos clientes de Supabase (staff y customer), utilidades
│ └── components/ # rutas protegidas
├── supabase/migrations/ # Esquema SQL completo + datos de ejemplo
└── .env.example
1. Configurar Supabase
- Crear un proyecto en supabase.com.
- Ir a SQL Editor y ejecutar, en orden:
supabase/migrations/0001_init.sql (tablas, seguridad, triggers)supabase/migrations/0002_seed.sql (datos de ejemplo: 1 local, zonas, productos)supabase/migrations/0003_payment_proof.sql (soporte para comprobante de transferencia)supabase/migrations/0004_customer_identity.sql (clientes sin login + roles de staff admin/camarero)
- Ir a Authentication > Providers y confirmar que Email esté
habilitado (esto es solo para el login del staff, los clientes no usan
Supabase Auth).
- Crear tu primer usuario admin: desde Authentication > Users,
crear un usuario manualmente con email y contraseña (botón "Add user").
Copiá su UUID y en el SQL Editor ejecutá:
insert into profiles (id, full_name, role) values ('EL-UUID-DEL-USUARIO', 'Tu nombre', 'admin');
- Para crear usuarios camarero más adelante, repetir el paso 4 con
role = 'camarero'. No hay pantalla en la app para esto — es
intencional, para que nadie pueda otorgarse acceso de staff por su
cuenta.
- Copiar Project URL y anon public key desde Project Settings > API.
Cargar mesas y sectores
El cliente elige su ubicación de una lista agrupada en dos partes: Mesas
(sector restaurante/bar) y Sectores generales (tribuna, juegos, cancha
de pádel, etc — cualquier zona del club donde alguien pueda pedir sin tener
una mesa asignada). Ambos se cargan en la tabla venue_zones, diferenciados
por la columna type (mesa o zona). El seed (0002_seed.sql) ya trae
un ejemplo de cada uno; para agregar más:
insert into venue_zones (venue_id, name, type, sort_order) values
('00000000-0000-0000-0000-000000000001', 'Mesa 5', 'mesa', 9),
('00000000-0000-0000-0000-000000000001', 'Pileta', 'zona', 10);
2. Cómo funciona el pago en este MVP
No hay pasarela de pago online conectada todavía. El cliente elige una
forma de pago al confirmar su pedido:
- Transferencia por alias — si definís
VITE_TRANSFER_ALIAS, esta
opción aparece. El cliente ve el alias, transfiere desde su billetera
virtual, y sube una foto del comprobante desde la app. El pedido queda
en estado "pendiente de pago" con el comprobante visible para el cajero
en el panel admin, quien lo confirma o rechaza con un botón.
- Efectivo — el pedido queda en una cola "Por cobrar en persona" en el
panel admin. Un mozo se acerca a la ubicación indicada a cobrar, y
cuando lo cobró, lo marca como "pago recibido" desde el panel — recién
ahí el pedido pasa a la cola de preparación.
- Tarjeta — igual que efectivo, pero el mozo se acerca con el posnet.
Si no definís VITE_TRANSFER_ALIAS, solo aparecen las opciones de efectivo
y tarjeta.
3. Variables de entorno
Copiar .env.example a .env y completar:
VITE_SUPABASE_URL=...
VITE_SUPABASE_ANON_KEY=...
VITE_VENUE_ID=00000000-0000-0000-0000-000000000001
VITE_TRANSFER_ALIAS=mirestaurante.mp (opcional, ver sección de pagos)
Todas estas son públicas (van al frontend) — no hay variables privadas en
esta versión, porque no hay backend propio ni pasarela de pago conectada.
4. Correr en local
npm install
npm run dev
5. Deploy
- Subir este proyecto a un repositorio de GitHub.
- En vercel.com (o Netlify, o cualquier hosting de
sitios estáticos), importar el repositorio.
- Agregar las variables de entorno del paso 3 en la configuración del
hosting.
- Deploy. Vercel detecta Vite automáticamente.
Cómo usar
Cliente
https://tu-app.vercel.app → la primera vez, ingresa nombre y WhatsApp →
ver carta → agregar items → elegir ubicación (mesa o sector general, de
una lista) → elegir forma de pago → confirmar → ver estado del pedido. En
visitas siguientes desde el mismo celular, entra directo a la carta.
Staff
https://tu-app.vercel.app/admin/login → ingresar con cuenta de rol
admin o camarero → ver comprobantes y cobros pendientes arriba del
tablero (con WhatsApp del cliente para contactarlo) → ver tablero de
pedidos → marcar siguiente estado → ver historial completo en "Historial"
→ editar la carta en "Editar carta" (solo admin).
Notas técnicas sobre la identidad sin login
Por seguridad, un cliente sin login no puede ver los pedidos de otro: cada
dispositivo genera un token secreto (no solo un id), y las políticas de
seguridad de la base de datos (RLS) exigen ese token para leer o crear
pedidos — no hay tabla abierta a cualquiera con la clave pública del
proyecto.
Una limitación de esto: las suscripciones en tiempo real de Supabase
(Realtime/WebSocket) no propagan ese token por una limitación conocida de
la plataforma. Por eso la pantalla de seguimiento del pedido del cliente
usa actualización periódica (cada 6 segundos) en lugar de tiempo real
instantáneo. El panel del staff sí usa tiempo real real, porque ahí la
sesión es de Supabase Auth normal.
Roles
- Cliente: sin rol, sin cuenta. Identificado por nombre + WhatsApp +
token de dispositivo. Solo ve sus propios pedidos.
camarero: ve y gestiona todos los pedidos del local, contacta clientes.admin: igual que camarero, más gestión de carta y precios.
Limitaciones conocidas del MVP (a definir en próximas iteraciones)
- Un solo local (
venue). El esquema ya soporta multi-local, falta la UI.
- No hay división de cuenta entre varias personas en la misma mesa.
- No hay notificaciones push para el cliente (el estado se actualiza por
sondeo periódico mientras tiene la pestaña/app abierta).
- No hay panel de métricas (ventas, productos más pedidos).
- Las fotos de productos se suben pegando una URL, no hay subida directa
de imagen desde el editor de carta.
- No hay pasarela de pago online conectada (queda para una próxima etapa).
- Sin selector de ubicación por mapa/vista aérea por ahora — el esquema lo
soporta (
location_type = punto_mapa, columnas map_x/map_y) pero el
flujo del cliente quedó simplificado a una lista de mesas y sectores.
- El WhatsApp del cliente no está verificado — cualquiera puede escribir
cualquier número. Aceptable para contacto operativo, no para identidad
verificada.
