Una burger, cinco puertas y una sola cocina: así construimos el sistema de ventas de El As de las Burgers

Pedir una hamburguesa parece sencillo. Un cliente lo hace desde el móvil, otro en la pantalla del local, otro desde Uber Eats y, en caja, alguien cobra en efectivo. Para el cliente son cinco experiencias distintas. Para la cocina tiene que ser una sola cola, con el mismo precio, los mismos alérgenos y el mismo ticket impreso.

Eso fue lo que construimos para El As de las Burgers entre mayo y octubre de 2026. Empezamos con un prototipo mínimo y hoy el sistema atiende cinco canales de venta a la vez. Contamos qué hicimos y, sobre todo, las decisiones que lo hacen fiable.

Cinco puertas, una cocina

El sistema se compone de cinco aplicaciones que comparten las mismas reglas:

• Web de clientes: carta, carrito, recogida o domicilio, pago y seguimiento del pedido.
• App móvil: la misma experiencia de forma nativa, con puntos de fidelización (AS Points).
• Kiosko de autopedido: el cliente personaliza su pedido en una pantalla del local.
• Caja: cobro en efectivo o con datáfono, arqueo de caja y administración del catálogo.
• Cocina: una pantalla en tiempo real con los pedidos, el reparto y las métricas.

A ellas se suma Uber Eats, cuyos pedidos entran directamente en la pantalla de cocina. El resultado es que el equipo mira un solo lugar, sin importar por dónde llegó cada pedido.

De un servidor propio a «la base de datos primero»

La primera versión tenía un servidor propio con colas y conexiones en tiempo real. Funcionaba, pero cada canal nuevo suponía trabajo nuevo en ese servidor.

El 7 de julio dimos un paso decisivo: trasladamos las reglas del negocio a la base de datos. Las pantallas de cocina, caja, kiosko y web dejaron de depender de un servidor intermedio y pasaron a hablar con la base de datos mediante funciones controladas y actualizaciones en tiempo real. Los pagos y las integraciones con terceros se resuelven con funciones sin servidor, que se activan solo cuando hacen falta.

La consecuencia práctica es que añadir un canal ya no exige tocar el motor. Se conecta a las mismas reglas y las hereda.

El navegador muestra, el servidor decide

Es la regla más importante del proyecto. Precio, horario, pedido mínimo, distancia de reparto y disponibilidad por canal se validan en el servidor. Si alguien manipulara la web, el pedido se rechazaría igualmente. Esto se traduce en decisiones concretas:

• El precio lo calcula el servidor. Combos, extras y salsas se recalculan al crear el pedido. En las salsas, la primera es gratis y las adicionales se cobran por cantidad.
• Los alérgenos solo suman. Al añadir un extra se suman sus alérgenos y trazas, según los 14 que define la normativa europea. Al quitar un ingrediente no se restan: por seguridad, la ficha nunca promete menos de lo que puede haber.
• El carrito se reconcilia. Si un producto cambia de precio o se agota mientras el cliente decide, el carrito se ajusta y se le avisa antes de pagar.
• Los pagos no se duplican. La web admite tarjeta y Bizum. Los avisos del banco son idempotentes: si llega el mismo aviso dos veces, no se crea un segundo pedido. Los pagos abandonados caducan solos.
• Cada producto sabe cómo puede salir. Hay productos que solo se sirven para recoger. La regla vive en la base de datos, así que ningún canal puede colarlos a domicilio.

La cocina manda

Los pedidos aparecen en la pantalla de cocina en el momento en que se confirma el pago, y el contador de preparación arranca solo. Las comandas se imprimen en una impresora térmica conectada por WiFi, directamente desde el iPad de cocina, y cada impresión queda registrada.

La cocina también gobierna el reparto. Radio, tarifa, pedido mínimo, envío gratis y horario se configuran una sola vez. La web y el pago leen el mismo valor, así que no hay copias que se desajusten. Si hay saturación, el equipo apaga los domicilios desde la pantalla de cocina y la web deja de ofrecerlos al instante.

El kiosko permite personalizar con el nivel de detalle de las grandes cadenas: tamaños, extras con coste, quitar ingredientes y combos con elección de bebida. Cada combo genera una línea con el precio total y líneas por componente, que van a la estación de cocina que corresponde.

Cuando Uber dijo «todavía no»

El 25 de agosto, Uber rechazó la revisión de producción de nuestra integración y señaló nueve capacidades que debíamos demostrar. Hicimos una lista, la tratamos como un plan de trabajo y fuimos cerrando cada punto con pedidos reales como evidencia:

• Recibir y aceptar pedidos.
• Marcar un pedido como listo, cancelarlo o rechazarlo.
• Gestionar el menú y marcar un producto como agotado.
• Abrir y cerrar la tienda.
• Activar la integración desde la cuenta del comerciante.

Hoy las nueve están confirmadas. Además de la aprobación, el ejercicio nos dejó un registro de cada llamada y de cada respuesta, que nos sirve para diagnosticar cualquier incidencia.

En números

Entre el 12 de mayo y el 8 de octubre de 2026 el proyecto acumuló 261 cambios en el código. Hoy lo forman cinco aplicaciones, cerca de 29.000 líneas de código de interfaz, 22 funciones sin servidor y más de 50 migraciones de base de datos. Más de treinta documentos acompañan al código: guías de despliegue, de la impresora, de Uber Eats y de cumplimiento normativo.

Lo que hemos aprendido

Tres ideas resumen el proyecto:

• Una sola fuente de verdad. Cuando el mismo dato vive en dos sitios, tarde o temprano discrepan. Precios, radio de reparto y disponibilidad viven en un único lugar.
• La seguridad se diseña desde el principio. Permisos por rol, secretos de pago en el servidor y pruebas en entornos separados de producción.
• Documentar mientras se construye. Es lo que permite retomar el trabajo al día siguiente sin perder el hilo.

Lo que viene

Seguimos midiendo y mejorando: analítica de la web, panel de operación con pedidos, clientes y productos más vendidos, y nuevas formas de fidelización. Si quieres construir un sistema de ventas multicanal para tu negocio, en Pro Corp lo diseñamos a medida.