MesitaQR · Reporte técnico para socios

Qué se construyó,
cómo funciona,
cómo probarlo.

Esta etapa se completó en tres relevos de trabajo. El resultado: la demo pública corre sobre el motor real, los dashboards muestran números verdaderos, el dinero cuadra al centavo, y todo está publicado y probado. Este documento explica cada cambio sin tecnicismos — y con la profundidad completa disponible para quien quiera abrirla.

672tests automáticos
7/7pruebas e2e contra producción
3relevos completados
$0.00de error de centavos permitido
01Resumen ejecutivo

Qué se logró en esta etapa

El trabajo se organizó como una carrera de relevos: tres personas, tres capas. Cada quien construyó su parte, la probó a fondo, y le entregó al siguiente un documento de traspaso con todo verificado. Nadie tocó producción hasta el final.

En una frase por relevo:

La disciplina del método se nota en un solo dato: la cantidad de pruebas automáticas solo creció de relevo en relevo — 477 → 604 → 672. Nadie rompió lo del anterior.

Narrativa hablada "El riesgo clásico de construir software entre varias personas es que cada uno rompa lo del anterior sin darse cuenta. Aquí cada relevo entregó con evidencia: pruebas automáticas que cualquiera puede volver a correr, y un documento de traspaso. Hoy les muestro qué quedó construido y cómo lo pueden probar ustedes mismos."
02Todo es real y público

Todo lo que ya está en vivo

Cada link de esta tabla abre una pieza funcionando en producción, ahora mismo, desde cualquier celular. Nada es un video ni una maqueta.

Qué esLink
🏠 Central de accesos (índice de todo)mesitademo-two.vercel.app/accesos
📱 App del cliente — Mesa 12 demo públicamesitademo-two.vercel.app/pay/demo
🖥️ POS (simulador de la caja)mesita-pos.vercel.app/index.html
📊 Dashboard del dueño — Panel…/dashboard/owner/panel
📈 Dashboard — Estadísticas…/dashboard/owner/estadisticas
🪑 Dashboard — Mesas (QRs)…/dashboard/owner/mesas
🍽️ Dashboard — Menú…/dashboard/owner/menu
👥 Dashboard — Personal…/dashboard/owner/personal
↩️ Dashboard — Reembolsos…/dashboard/owner/reembolsos
⚙️ Dashboard — Configuración…/dashboard/owner/configuracion
🛡️ Admin de plataforma (super-admin)mesitademo-two.vercel.app/admin
🖨️ Póster QR de la Mesa 12…/pay/demo/qr
📰 Bitácora pública de cambiosmesitademo-two.vercel.app/cambios
💻 Código de la appgithub.com/manuelmmontufarm-dev/mesita-app
💻 Código del POSgithub.com/manuelmmontufarm-dev/pos-mesita-demo
Para ir más hondo: nota sobre los dominios

mesitademo-two.vercel.app y mesita-app.vercel.app apuntan al mismo proyecto de producción en Vercel. mesita-app.vercel.app es el origen canónico que se imprime en los QRs físicos (configurado en la variable NEXT_PUBLIC_APP_URL). El POS vive en su propio proyecto: mesita-pos.vercel.app.

03Lo nuevo · primer relevo

Relay 01 · Cimientos y contrato con el POS

El objetivo de este relevo fue que el dinero y los datos sean incorruptibles, y que la conexión con el sistema de caja del restaurante quede resuelta desde el diseño.

Relay 01 · Manuel

Qué quedó construido

  • Contrato Contífico v2, congelado. Es un documento exacto — palabra por palabra — de cómo la app habla con el POS: cómo se identifica, cómo pide la cuenta de una mesa, cómo registra un cobro, y cómo se mapea cada mesa (MESITA_TABLE:<id>). Está protegido por 19 pruebas automáticas: si alguien cambia algo que rompe el acuerdo, las pruebas fallan al instante. El simulador del POS implementa ese contrato idéntico, así que pasar al Contífico real es solo cambiar dos datos de configuración (la dirección y la llave de acceso) — cero código nuevo.
  • La base de datos es la única fuente de verdad. Todo lo que importa — quién está en la mesa, qué plato reclamó cada quien, qué pagos se hicieron — vive en una sola base de datos (Supabase). Si la pantalla de alguien dice una cosa y la base dice otra, gana la base. Refrescar la página nunca duplica a una persona: cada comensal tiene una credencial única por cuenta.
  • Un pago nunca se cobra dos veces. Las redes de celular fallan y los botones se tocan dos veces. El sistema está diseñado para que dé igual: se comprobó que 20 reintentos idénticos producen exactamente 1 pago en la base.
  • Consultas al POS con turnos. Cuando 10 personas miran la misma mesa a la vez, solo una consulta viaja al POS; las demás leen la última copia guardada. Medido en producción: 564 lecturas de pantalla se convirtieron en solo 31 consultas al POS, sin un solo fallo, y el 95% de las lecturas tardó 1.5 segundos o menos.
  • Seguridad revisada: el número de tarjeta y el CVV jamás tocan nuestro servidor; la llave de pruebas que quedó escrita en el código está marcada para rotarse antes de conectar el sistema real.
✓ App 477/477 pruebas · POS 47/47 · concurrencia: 10 rondas × 9/9 contra la base real
La idea en simple Piensen en el contrato con el POS como un enchufe estandarizado: hoy está enchufado un generador de pruebas (el simulador), y el día que llegue la conexión real de Contífico, se desenchufa uno y se enchufa el otro. El enchufe no cambia.
04Lo nuevo · segundo relevo

Relay 02 · Dashboards, admin y el ciclo de vida de los QRs

El objetivo: que solo las personas correctas puedan hacer las cosas correctas, y que los números que ve el dueño sean siempre verdaderos.

Relay 02 · Alejandro

Qué quedó construido

  • Una sola política de permisos. Hay dos niveles de acceso: el super-admin de la plataforma (con la clave maestra ADMIN_SECRET) y el dueño/manager de cada restaurante (con login propio, limitado a su restaurante). El rol de mesero quedó fuera de este release a propósito: cualquier intento recibe "acceso denegado". La tabla completa de "quién puede hacer qué" está fijada con pruebas automáticas — si un cambio futuro afloja un permiso por accidente, una prueba truena.
  • Ciclo de vida de mesas y QRs. Cada mesa se crea con un código único imposible de adivinar, que nunca cambia. Apagar o prender el QR de una mesa es potestad exclusiva del super-admin, con registro de quién lo hizo y cuándo. Y apagar un QR revoca todo: ver la mesa, unirse, e incluso pagar desde una pantalla que alguien ya tenía abierta.
  • Dashboards honestos. Cada número del panel sale de una consulta real a la base de datos: Ingresos = suma de pagos completados del día; Ticket promedio = promedio de cuentas cerradas (sin propina); Propina = suma de propinas voluntarias. No hay un solo número inventado ni de relleno: un día sin ventas muestra "cero verificado", y si la base de datos está caída, se muestra un error con un código de rastreo — nunca un número falso.
  • Alarmas y rastreo de errores. Cada operación deja un registro estructurado con un ID de rastreo, y los errores de producción se capturan automáticamente (Sentry) con todo su contexto. Si algo falla, sabemos exactamente qué, dónde y a quién le pasó.
✓ 604 pruebas · QA en vivo sobre preview: 8 jornadas × 3 tamaños de pantalla
La idea en simple Hay una llave maestra de la plataforma y una llave por dueño que solo abre su restaurante. Y el tablero de números nunca maquilla nada: si hoy no se vendió, dice cero; si no puede consultar, dice "error" con su código — jamás muestra un número bonito para quedar bien.
05Lo nuevo · tercer relevo

Relay 03 · La demo pública ahora corre sobre el motor real

El cambio más importante de esta etapa: lo que se prueba en la Mesa 12 ya no es una maqueta — es el producto. La demo usa exactamente el mismo motor que usarán las mesas de los restaurantes reales.

Relay 03 · Juan Javier

Qué quedó construido

  • Un solo motor. Antes, la Mesa 12 (/pay/demo) funcionaba con una memoria temporal aparte, montada solo para demostraciones. Ahora corre sobre el mismo motor y la misma base de datos que las mesas reales: sesiones, reclamos de platos y pagos de verdad. Las mesas de utilería 1–4 se cerraron en producción (dan 404).
  • Dinero exacto al centavo, en los 3 modos de división. Se encontraron y arreglaron tres variantes del mismo error de redondeo que podía dejar al último pagador atascado con un centavo imposible de saldar. La historia completa está en la sección 06 — vale la pena.
  • Las pantallas convergen solas. Si un amigo paga todo desde su celular, la pantalla de los demás se entera en segundos y navega sola a "¡Cuenta saldada!". Los recibos sobreviven recargas de página. "Ver la mesa" funciona sin rebotar.
  • Renovación por escaneo (sin relojes). Quien pagó conserva su recibo para siempre. El próximo visitante nuevo que escanea el QR abre una mesa fresca, sin deudas ajenas, con el menú demo. No hay temporizadores que borren nada.
  • El panel demo se mueve en vivo: pagas en el celular y el panel y la barra de actividad reaccionan delante de ti, porque leen la misma Mesa 12 del motor real.
  • Privacidad: el número de tarjeta y el CVV jamás se guardan — ni en el navegador ni en el servidor.
✓ 672 pruebas (660 corren en cualquier máquina + 12 requieren la base conectada) · e2e Playwright 7/7 contra el deploy real, incluye 10 comensales a la vez

Cómo quedó la experiencia, en 5 pasos

paso 1Escanea el QRSe abre la app en el navegador — sin descargar nada.
→
paso 2Entra con su nombreVe a los demás aparecer en vivo, cada uno con su color.
→
paso 3Reclama sus platosToca lo que consumió. Nadie puede reclamar el plato de otro.
→
paso 4Paga a su maneraTodo, partes iguales, o por plato. Propina opcional.
→
paso 5¡Mesa cerrada! 🎉Todas las pantallas convergen a "Cuenta saldada" — con confeti.
Narrativa hablada "Esto pueden probarlo ustedes mismos ahora, desde sus celulares, entre dos o más. Y quiero subrayar el punto clave: ya no hay una 'versión demo' y una 'versión real' — es un solo motor. Lo que ven funcionar es lo que se instalará en los restaurantes."
06Historia técnica favorita

La caza del medio centavo

Una historia corta que muestra el nivel de rigor con el que se trabajó — y por qué "casi exacto" no sirve cuando se trata de dinero.

Cuando una cuenta impar se divide entre varias personas, aparece un medio centavo que no existe en el mundo real. Ejemplo: $10.01 entre dos son $5.005 cada uno — y nadie puede pagar medio centavo. Si la app redondea sin cuidado, ambos pagan $5.01 (sobra un centavo) o ambos pagan $5.00 (falta uno)… y la última persona queda atascada frente a una cuenta que dice "te falta $0.01" imposible de saldar.

Este mismo error apareció disfrazado tres veces: en el modo "Todo", en propinas que generaban medio centavo, y en el pago "por plato". Las tres variantes se reprodujeron contra el sistema real del entorno de pruebas, se corrigieron, y se verificaron en vivo. La solución no fue cosmética sino de fondo: toda la aritmética de dinero se hace ahora en centavos enteros (nunca en decimales que puedan generar fracciones), y el pago que cierra la mesa cobra exactamente el resto autorizado por el guardián de saldos. El resultado no depende de la suerte — está garantizado por construcción.

07Cómo funciona

Cómo funciona por dentro: las piezas

El sistema no corre en servidores propios: se apoya en servicios especializados, cada uno con un rol claro. Aquí está cada pieza y qué hace, sin tecnicismos:

Vercel · donde la app vive y atiende al público

Cada vez que el código cambia, Vercel construye una copia nueva de la app y la publica. Mantiene dos ambientes: los de ensayo (preview) — cada línea de trabajo recibe su propia copia con dirección propia, donde se prueba todo — y el de producción, que es lo que ven los clientes. Si algo sale mal, se regresa a la versión anterior con un clic.

GitHub · el historial completo del código

Guarda cada versión que ha existido. Cada cambio queda registrado con autor, fecha y explicación (un "commit"). Las ramas son borradores de trabajo; la rama main es la versión oficial que alimenta producción. Nada llega a los clientes sin pasar por este registro.

Supabase (Postgres) · la base de datos — la fuente de verdad

Guarda restaurantes, mesas, cuentas, comensales, reclamos de platos y pagos. Es la única fuente de verdad: si una pantalla y la base no coinciden, gana la base. La app se conecta a través de un repartidor de conexiones ("pooler"), necesario porque Vercel abre muchas conexiones pequeñas a la vez.

Prisma · el traductor entre el código y la base

El código y la base de datos hablan idiomas distintos. Prisma traduce entre los dos, define la estructura de la base (qué tablas existen y qué guarda cada una) y administra las "migraciones": los cambios de estructura sin perder datos.

Redis / Upstash · memoria rápida y desechable

Se usa solo para el demo antiguo y para límites de tasa (impedir que alguien haga miles de peticiones por segundo). Nada importante vive ahí.

Sentry · la alarma de errores

Si algo se rompe en producción, Sentry lo captura con todo su contexto y un ID de rastreo que conecta lo que vio el usuario con los registros del servidor. Los problemas se detectan por la alarma, no porque un cliente se queje.

Contífico (hoy: simulador) · la caja del restaurante

El POS es el dueño de las órdenes y de la factura electrónica — eso no cambia. Hoy la app habla con un simulador que implementa el contrato idéntico al real; conectar el Contífico verdadero es cambiar dos datos de configuración.

Narrativa hablada "No mantenemos servidores propios: alquilamos las mejores piezas del mercado y las conectamos con disciplina. Eso significa costos bajos y predecibles mientras crecemos, y ninguna pieza es una caja negra: cada una tiene un rol claro y un reemplazo posible."
08El flujo completo

El viaje de un pago: del QR a la caja

Sigamos a un pago de principio a fin, por dentro del sistema:

1 · mesaQR → sesiónEl QR lleva un código único no adivinable. La app abre (o retoma) la sesión de esa mesa en la base de datos.
→
2 · cuentaLee el POSLa app le pregunta al POS "¿qué consumió esta mesa?" y muestra la cuenta en vivo.
→
3 · reclamoCada quien lo suyoLos reclamos de platos se guardan con candados que impiden que dos personas se queden con el mismo plato.
→
4 · cobroPago registradoAunque la red falle y se reintente 20 veces, se registra UNA sola vez.
→
5 · avisoEl POS se enteraMesitaQR registra el cobro en el POS, que sigue siendo dueño de la factura.
La idea en simple Si 10 personas tienen la mesa abierta en su celular, sería un desperdicio que las 10 pantallas le pregunten al POS lo mismo a la vez. En su lugar, una sola consulta viaja al POS, la respuesta se guarda como una "foto", y las otras 9 pantallas leen esa foto. Solo se vuelve a preguntar cuando la foto ya está vieja.
Para ir más hondo: los mecanismos y sus números medidos
  • Coalescing con "lease": por cada ventana de frescura, un solo proceso gana el turno de consultar al POS; el resto lee la copia guardada. Medido en producción: 30/30 muestras sin fallos, p95 de 1.5 segundos, 564 lecturas de pantalla → solo 31 consultas al POS.
  • Idempotencia: cada intento de pago lleva una clave única; la base acepta esa clave una sola vez. Verificado: 20 reintentos idénticos ⇒ exactamente 1 pago.
  • Credencial por comensal: cada persona recibe un clientToken único por cuenta — refrescar la página nunca crea un "comensal fantasma".
  • Candados de fila (FOR UPDATE en Postgres): dos personas tocando el mismo plato al mismo tiempo terminan con un solo dueño, siempre.
09Transparencia total

Qué está sólido — y qué falta todavía

Entre socios nos debemos claridad, no marketing. Esta es la fotografía honesta de hoy:

Sólido Verificado con evidencia

  • Concurrencia multi-comensal: 10 personas a la vez, disputas por platos, reintentos de pago — probado contra la base real.
  • Matemática de dinero exacta al centavo en los 3 modos de división.
  • Permisos por rol + revocación total del QR (hasta un pago en curso).
  • Dashboards con números reales de la base — cero datos inventados.
  • Conexión con el POS simulado: p95 1.5 s, consultas con turnos, medido con benchmark.
  • Proceso completo de publicación rama → ensayo → pruebas → producción, con marcha atrás en un clic.

Pendiente Deuda conocida — dicho claro

  • Pagos reales: hoy el cobro es simulado, válido solo para la mesa demo. La integración con Diners/Datafast no existe todavía — es el siguiente gran paso.
  • Contífico real nunca validado: todo se probó contra el simulador (que implementa el contrato). Falta rotar la llave de pruebas y validar contra el Contífico verdadero.
  • Reembolsos parciales no soportados: un reembolso revierte el pago completo.
  • Carga probada hasta 10 comensales simultáneos por mesa; no hay pruebas de estrés mayores.
  • Detalles cosméticos en lista de pendientes: estilo del anillo de progreso, texto "Faltan $X" con/sin propina, liberar un plato tarda 1–2 s en confirmar.
Narrativa hablada "Quiero ser muy claro con la columna derecha: el botón de pagar de la demo simula el cobro. Todavía no movemos dinero real — esa integración con la pasarela es el siguiente gran paso, y todo lo demás ya está construido esperándola."
10Configuración sin misterios

Variables de entorno — qué hace cada una

Son la configuración que cambia entre local, preview y producción sin tocar el código. Nunca se muestran sus valores reales aquí: esta tabla explica su función y si debe tratarse como secreto.

Regla de oro Todo lo que empieza con NEXT_PUBLIC_ llega al navegador y puede ser visto por cualquiera. Las llaves, contraseñas y tokens nunca llevan ese prefijo y se guardan solo en Vercel o en .env.local. La app y el POS son proyectos separados: cada uno tiene su propio juego de variables.
App MesitaQR · base de datos, acceso y comportamiento
VariablePara qué sirveTratamiento
DATABASE_URLConexión de ejecución a Supabase/Postgres; en Vercel usa el pool de transacciones.Secreta
DIRECT_URLConexión directa que Prisma usa para migraciones y mantenimiento, no para tráfico normal.Secreta
SEED_MODEElige si la carga inicial crea datos demo completos o el mínimo seguro de producción.Operativa
NEXTAUTH_SECRET / AUTH_SECRETFirma las sesiones de dueños y managers; rotarla obliga a volver a iniciar sesión.Secreta
NEXTAUTH_URLDirección base usada por Auth.js para callbacks de login.Operativa
ADMIN_SECRETClave maestra del super-admin para entrar a /admin y autorizar sus APIs.Secreta
ENCRYPTION_KEYCifra las credenciales de POS y pagos guardadas en la base. No se rota sin volver a guardar esas credenciales.Secreta crítica
PAYMENT_PROVIDERSelecciona el motor de pagos: STUB para demo o el proveedor real habilitado.Operativa
OWNER_READONLYActiva del lado servidor las restricciones de edición del panel del dueño.Operativa
NEXT_PUBLIC_OWNER_READONLYHace que la interfaz oculte o deshabilite controles de edición; debe coincidir con la regla del servidor.Pública
NEXT_PUBLIC_DEMO_PANELIndica al navegador que la experiencia demo del panel está disponible.Pública
ENABLE_DEV_LOGINHabilita el acceso automático local solo en desarrollo. Debe quedar vacío en cualquier deploy.Solo local
CRON_SECRETProtege las tareas automáticas y la sincronización programada.Secreta
VERCEL_ENVLa define Vercel para distinguir development, preview y production; la app la usa para cerrar rutas demo.Automática
App MesitaQR · URLs públicas, límites, correo y observabilidad
VariablePara qué sirveTratamiento
NEXT_PUBLIC_APP_URLOrigen canónico que se imprime en los QR físicos.Pública
NEXT_PUBLIC_DEMO_PAY_URLLink directo a la mesa de demostración.Pública
NEXT_PUBLIC_SUPABASE_URLURL pública del proyecto Supabase, reservada para clientes que lo necesiten.Pública
NEXT_PUBLIC_SUPABASE_ANON_KEYLlave anónima de Supabase; solo es segura con políticas RLS correctas.Pública controlada
UPSTASH_REDIS_REST_URLDirección de Redis usada para límites de solicitudes distribuidos.Operativa
UPSTASH_REDIS_REST_TOKENAutoriza a la app a usar Redis para proteger pagos, login y APIs contra abuso.Secreta
RESEND_API_KEYPermite enviar por correo los contactos recibidos desde la web.Secreta
CONTACT_EMAILDirección interna que recibe los mensajes de contacto.Privada
NEXT_PUBLIC_SENTRY_DSNEnvía errores del navegador al proyecto correcto de Sentry; no concede lectura.Pública
SENTRY_AUTH_TOKENSube mapas de código durante el build para que los errores sean legibles.Secreta
SENTRY_ORGOrganización de Sentry que recibe los reportes.Operativa
SENTRY_PROJECTProyecto de Sentry correspondiente a esta app y ambiente.Operativa
Conexión de la app con el POS y Contífico
VariablePara qué sirveTratamiento
POS_MESITA_API_URLDirección del POS simulador usada por la experiencia demo y sus pruebas.Operativa
POS_MESITA_API_KEYClave que permite a la app hablar con el API protegido del POS simulador.Secreta
CONTIFICO_BASE_URLCambia entre el simulador /sistema/api/v2 y Contífico real sin cambiar código.Operativa
CONTIFICO_API_KEYCredencial usada por las pruebas de conexión con Contífico.Secreta
CONTIFICO_TABLE_FIELDCampo del documento que guarda la identidad de mesa; por defecto adicional1.Operativa
CONTIFICO_ATTACH_CLIENTEActiva experimentalmente la creación/asociación de cliente; queda apagada hasta validarla.Bandera
CONTIFICO_PREVIEW_BYPASS_SECRETPermite que una preview protegida llame al simulador durante QA.Secreta temporal
POS_SYNC_FRESHNESS_MSTiempo mínimo entre consultas reales al POS; evita saturarlo cuando muchos comensales miran la mesa.Operativa
Proyecto Mesita-POS · servidor, QR y datos del restaurante
VariablePara qué sirveTratamiento
DATABASE_URLBase de datos del POS y de sus tenants.Secreta
NODE_ENVDistingue pruebas, desarrollo y producción; cambia validaciones y mensajes de error.Operativa
PORTPuerto local/Railway; Vercel administra el suyo automáticamente.Operativa
APP_BASE_URLDirección pública usada en callbacks y enlaces QR del POS.Operativa
API_KEYProtege el API v1 del POS; debe coincidir con POS_MESITA_API_KEY de la app.Secreta crítica
MESITAQR_BASE_URLDirección del servicio MesitaQR/Paga Ya al que el POS solicita sesiones.Operativa
MESITAQR_API_KEYAutoriza al POS ante ese servicio; vacía significa modo simulado.Secreta
MESITAQR_WEBHOOK_SECRETVerifica que una confirmación de pago entrante sea auténtica.Secreta crítica
MESITAQR_QR_EXPIRY_MINUTESMinutos de vigencia de una sesión QR pendiente.Operativa
CONTIFICO_ENABLEDActiva o desactiva el reenvío de documentos hacia Contífico.Bandera
CONTIFICO_BASE_URLDirección del API de Contífico usada por el POS.Operativa
CONTIFICO_TOKENCredencial del POS para enviar documentos al Contífico real.Secreta
PLATFORM_BOOTSTRAPPEDEvita repetir creación de esquemas/tablas en cada arranque cuando el despliegue ya está preparado.Operativa
RUN_PLATFORM_BOOTSTRAPOrdena al proceso de despliegue ejecutar explícitamente la preparación inicial de plataforma.Operativa temporal
RESTAURANT_RUCRUC mostrado en documentos demo del restaurante predeterminado.Dato fiscal
RESTAURANT_RAZON_SOCIALRazón social predeterminada para documentos demo.Dato fiscal
RESTAURANT_DIRECCIONDirección predeterminada que aparece en el encabezado del comprobante demo.Dato fiscal
11Proceso de publicación

Cómo llega un cambio a producción (sin sustos)

Nada aparece "de repente" frente a los clientes. Cada cambio recorre siempre el mismo camino, con puertas de control en cada paso:

developer registra el cambio → sube a GitHub → Vercel construye la copia de ensayo (~2 min)
→ pruebas automáticas + pruebas de punta a punta contra esa copia → QA de Manuel
→ rama de integración fable/integration-final → se fusiona a main
→ Vercel publica producción automáticamente → si algo sale mal: marcha atrás en 1 clic
La idea en simple Todo cambio se prueba primero en una copia de ensayo idéntica a la real, lo revisan las pruebas automáticas, lo revisa una persona, y solo entonces se publica. Y si aun así algo sale mal, hay un botón para volver a la versión de ayer al instante.

Además, la bitácora pública de cambios (/cambios) se actualiza sola leyendo el historial oficial del código: cualquiera — incluidos ustedes — puede ver qué cambió y cuándo, sin pedir permiso ni saber programar.

12Manos a la obra

Cómo usar cada cosa — guías paso a paso

🍽️ Como comensal (la demo estrella para hacer en la reunión)

  1. Abran mesitademo-two.vercel.app/pay/demo en dos celulares (o celular + laptop).
  2. Cada uno entra a la mesa con su nombre — y ve a los demás aparecer en vivo, cada quien con su color.
  3. Toquen platos para reclamarlos. Intenten reclamar el mismo: nadie puede quitarle el plato al otro.
  4. Uno paga "por plato" con la tarjeta de prueba (botón "Usar tarjeta de prueba"); el otro paga el resto. Ambas pantallas convergen a "¡Mesa cerrada!" con confeti.
  5. Abran una ventana de incógnito: mesa fresca, sin deudas ajenas — así funciona la renovación por escaneo.

📊 Como dueño (dashboard)

Se entra con el login de dueño (las credenciales demo las tiene Manuel — nunca se pegan en documentos). Qué ver: Panel = el pulso del día (ingresos, mesas activas, ticket promedio, propinas, actividad por hora). Estadísticas = ocupación y estado por mesa. Mesas = la lista con el QR imprimible de cada una (solo si está habilitado). Reembolsos = revertir un pago completo. Configuración = datos fiscales e integración con el POS.

Tip para la demo: paguen primero en la Mesa 12 desde el celular y luego abran el Panel — verán los números del día moverse con ese pago.

🛡️ Como super-admin

mesitademo-two.vercel.app/admin con la clave de plataforma (ADMIN_SECRET; la tiene Manuel). Aquí se crean restaurantes y mesas, y es el único lugar donde se puede apagar o prender el QR de una mesa — con diálogo de confirmación y registro de quién y cuándo.

🖥️ El POS (la caja simulada)

mesita-pos.vercel.app/index.html simula la caja del restaurante (órdenes, documentos, cobros). Sirve para demostrar el flujo completo de punta a punta: orden creada en el POS → aparece en el celular del comensal → pago en MesitaQR → el POS lo registra.

13Material visual

Capturas reales para la presentación

Estas son las 11 capturas que dan vida a la presentación. Cada tarjeta indica el link exacto y qué debe verse — se toman en unos 15 minutos siguiendo este orden:

📸 1La central completaHero del ecosistema + accesos rápidos./accesos
📸 2Lobby + cuenta compartida"Entrar a la mesa" y la cuenta con 2+ comensales y platos reclamados (colores por persona)./pay/demo
📸 3Pantalla de pagoTarjeta de prueba y desglose: subtotal, IVA 15%, servicio 10%, propina./pay/demo
📸 4"¡Mesa cerrada!"Pantalla final con el resumen "Ya pagaron" y montos reales./pay/demo
📸 5Panel del dueñoKPIs del día con datos reales (tomar DESPUÉS de pagar en la demo)./dashboard/owner/panel
📸 6EstadísticasMapa de mesas con estados: Abierta / Pagando / Pagada./dashboard/owner/estadisticas
📸 7Mesa con su QRTarjeta de una mesa con su QR y el mapeo POS./dashboard/owner/mesas
📸 8Admin de plataformaLista de restaurantes y el interruptor de QR con su diálogo de confirmación./admin
📸 9El POS en acciónPantalla de mesas/órdenes y un documento con cobro registrado vía Mesita.mesita-pos.vercel.app
📸 10Bitácora públicaLa página /cambios — muestra la transparencia del proceso./cambios
📸 11Dashboard de VercelLista de publicaciones production/preview (captura desde la cuenta de Vercel).Cuenta de Vercel de Manuel
14Cierre

Números finales y próximos pasos

El estado del proyecto, en una pantalla

672pruebas automáticas (660 + 12 con base de datos)
7/7pruebas e2e contra el deploy real
3relevos completados con traspaso
40+cambios publicados en producción
1.5sp95 de la sincronización con el POS
10comensales concurrentes probados

Lo que falta, dicho sin rodeos: pagos reales (Diners/Datafast) y la validación contra el Contífico verdadero. Todo lo demás — motor, dashboards, seguridad, QRs, proceso de publicación — ya existe y está probado.

Siguientes pasos sugeridos:

  1. Integrar la pasarela de pagos real (Diners/Datafast) — el hueco más grande entre la demo y un restaurante cobrando de verdad.
  2. Validar contra Contífico real: rotar la llave de pruebas y correr el contrato v2 contra el POS verdadero (por diseño, debería ser solo configuración).
  3. Piloto en un restaurante amigo: una mesa real, un servicio real, con el equipo mirando.
  4. Robustecer: reembolsos parciales, pruebas de estrés más allá de 10 comensales, y los detalles cosméticos de la lista de pendientes.
Narrativa hablada — cierre "Lo que vimos hoy no son promesas: son links que funcionan, 672 pruebas automáticas que corren solas, y una lista honesta de lo que falta. El siguiente paso es uno solo y está clarísimo: conectar los pagos reales. La mesa está servida."