Soluciones · Restaurantes y HoReCa
El menú de un local no es un folleto: tiene precios y volúmenes que deben ser exactos, cambia a menudo y lo leen personas que hablan tres idiomas. Construimos el menú como datos, generamos la página a partir de ellos y verificamos antes de cada publicación, incluso que los precios bajen en cada categoría y que cada foto exista.
Ya construidoDouă meniuri digitale în producție, verificabile din exterior azi. Primul: 119 produse în 21 de categorii, cu preț, volum, compoziție și fotografie, plus câte un text scurt de prezentare și un set de recomandări de asociere pentru fiecare produs; generatorul are 402 linii, iar verificarea dinaintea publicării are 233 de linii și 16 blocuri. Al doilea, site-ul-soră cu același motor: 146 de produse în 31 de categorii, generator de 377 de linii, verificare de 210 linii cu 14 blocuri, iar integrarea continuă regenerează pagina din surse și respinge modificarea dacă rezultatul diferă de fișierul din depozit. Ambele răspund 200 și niciunul nu pune vreun cookie — verificat de mine pe 06.09.2026. Spunem și că sunt două lucrări cu același motor și același proprietar, nu două lucrări independente.
Un PDF escaneado en un código QR no resuelve nada de lo que un local tiene que resolver. No se busca en él, no se traduce, no se amplía bien en el teléfono y no se puede cambiar sin volver a imprimir el código. Y el menú cambia a menudo: la cocina saca un plato, el bar recibe otra marca, el precio de una posición sube. El menú es un conjunto de datos que se modifica semanalmente, no un documento impreso una sola vez.
Por eso lo tratamos como datos. Las fuentes reales son unos pocos archivos estructurados — productos, textos de presentación, recomendaciones de combinación, traducciones — y un generador escrito en Python compone a partir de ellos una sola página. En uno de los locales: 119 productos en 21 categorías, cada uno con precio, volumen, composición y fotografía, además de 119 textos breves y 119 conjuntos de «con qué combina». En el otro: 146 productos en 31 categorías. La página no se edita directamente — se regenera.
La traducción no se detiene en los botones. El rumano es la base, y el ruso y el inglés cubren las categorías, las denominaciones, los volúmenes, las composiciones, las 82 etiquetas de sabor y todos los textos de presentación. En una ciudad en la que la mesa vecina pide en otro idioma, un menú traducido a medias es más molesto que uno no traducido: te deja creer que puedes leerlo todo.
La parte que consideramos más importante y que nadie pide en el brief: el carrito, la lista de favoritos y el reparto de la cuenta se ejecutan en el navegador, sin cuenta y sin servidor, y el sitio no pone ninguna cookie ni pide nada a un dominio tercero. No es una promesa de la política de privacidad — es una regla impuesta por verificaciones automáticas que se ejecutan antes de cada publicación y que rechazan el cambio si ha aparecido algún rastreador, algún recurso externo o alguna fuente tomada de otro sitio.
Qué incluye
Los productos, los textos de presentación, las recomendaciones y las traducciones están en archivos estructurados; un generador escrito en Python — 402 líneas en uno local, 377 en el otro — compone a partir de ellos una sola página. La página publicada no se edita a mano; cuando alguien lo hace, la integración continua lo detecta, porque regenera la página y compara el resultado.
En un bar, el volumen forma parte del precio: la misma denominación a 40 y a 100 mililitros son dos productos distintos, y el cliente que no ve el volumen cree que se le dijo otra cosa. La estructura de datos mantiene los cuatro campos como obligatorios, no como opcionales, precisamente para que una posición incompleta no llegue a la mesa.
La traducción cubre la interfaz, las categorías, las denominaciones, los volúmenes, las composiciones, las 82 etiquetas de sabor y todos los textos breves de presentación, teniendo cada clave rumana su pareja en ruso e inglés. Una de las verificaciones previas a la publicación falla si el menú no está completo en los tres idiomas.
Sin cuenta, sin servidor, sin datos enviados a ninguna parte. El cliente compone su pedido en el teléfono y se lo muestra al camarero o lo usa para repartir la cuenta. Consecuencia técnica: no existe una base con lo que han pedido tus clientes, porque no se crea ninguna.
Verificado desde fuera: ningún encabezado de cookie en ninguno de los dos sitios, y la política de contenido de uno de ellos no permite absolutamente nada de fuera. Las fuentes están alojadas en el mismo dominio, no en un servicio externo. Las únicas direcciones externas de la página son los enlaces a las redes sociales del local — que pulsa el visitante, no los llama la página.
Dieciséis bloques de verificación en un local, catorce en el otro: sin rastreadores, sin recursos cargados automáticamente de terceros, fuentes autohospedadas, archivos estructurados válidos, cada fotografía existe, el menú completo en tres idiomas, los datos estructurados de la página válidos y — la que sorprende a todos — los precios descienden en cada categoría. Un precio introducido erróneamente se ve como una discontinuidad en el orden de la lista, no en la reclamación del cliente.
En cada modificación, la integración continua regenera la página desde las fuentes y rechaza el cambio si el resultado difiere del archivo del repositorio. Es la única garantía real de que lo que está en la pantalla del cliente viene de los datos que edita el local, y no de una intervención manual olvidada allí hace tres meses.
En la configuración del servidor de uno de los locales: máscara sobre las direcciones IP, encabezados de identificación borrados del registro y conservación limitada, con referencia explícita al principio de limitación del almacenamiento. La integración continua rechaza la modificación si de la configuración desaparecen estas líneas — así que la protección no puede perderse en silencio con un cambio de servidor.
No toma el pedido en la cocina ni confirma una reserva: para eso hace falta una conexión al sistema operativo del local, que es un trabajo aparte. Y no publicamos funciones que prometan algo que deba cumplirse en caja — un descuento de tipo «happy hour» o un horario de cocina no se activan sin el acuerdo escrito del local, porque quien paga por la promesa en pantalla es el de la caja.
Traseul
La primera entrega es el menú como datos: categorías, posiciones, precio, volumen, composición, fotografía. Aquí también se descubren las carencias: posiciones sin volumen, categorías que en realidad son dos, productos sin fotografía. Un menú digital construido sobre datos incompletos parece incompleto, por muy bueno que sea el diseño.
Las categorías, los nombres, los volúmenes, las composiciones, las etiquetas de sabor y los textos de presentación reciben sus pares en ruso e inglés. Entregamos el menú completo en tres idiomas y la verificación automática que falla si una clave queda sin traducir.
Sin rastreadores, sin recursos de terceros, fuentes autoalojadas, archivos válidos, cada fotografía presente, precios en orden descendente por categoría, datos estructurados válidos. Entregamos el script de verificación en el repositorio, para que el local también pueda ejecutarlo sin nosotros.
La publicación se hace al fusionar el cambio, después de que la integración continua haya regenerado la página y la haya comparado con las fuentes, y después de que se haya guardado una copia de la versión anterior. Entregamos los accesos y el procedimiento de reversión — no solo el sitio en marcha.
Los datos
Las reglas difieren de una industria a otra. Estas son las que se aplican en restaurantes & horeca.
Un caso
La situación
En un menú con más de cien posiciones, el error más frecuente no es de diseño, sino de tecleo: una cifra de más en un precio o una posición que quedó sin fotografía. Ambas se descubren, por lo general, cuando el cliente se las muestra al camarero.
Qué construimos
Antes de publicar, pusimos un script de verificación — 233 líneas en un local, 210 en el otro — que ejecuta dieciséis, respectivamente catorce bloques: que no se haya colado ningún rastreador, que la página no pida nada a un dominio de terceros, que las fuentes estén alojadas localmente, que los archivos de datos sean válidos y cada fotografía exista, que el menú esté completo en los tres idiomas, que los datos estructurados de la página sean válidos y que los precios bajen en cada categoría. Por separado, la integración continua regenera la página desde las fuentes en cada modificación y la rechaza si el resultado difiere del archivo publicado.
Qué salió
Un error de mecanografía en el precio rompe el orden descendente y detiene la publicación, y una fotografía faltante nunca llega a la pantalla de la mesa. La página publicada siempre corresponde a los datos que edita el local, porque si no, no se publica.
Qué no dice el caso
Las verificaciones detectan lo que se puede verificar mecánicamente. Un precio introducido mal, pero plausible — y en orden — pasa; para eso no existe otro mecanismo que alguien que lo mire. La documentación de uno de los proyectos dice «14 verificaciones» donde el script tiene 16 bloques; la cifra correcta es la del script.
Preguntas
Sí. Se editan los datos, no la página; la página se regenera a partir de ellos. La integración continua verifica la regeneración en cada modificación y rechaza la modificación si la página publicada ya no coincide con las fuentes. Así no existe el escenario en que alguien corrigió un precio directamente en la página y el cambio desapareció en la siguiente publicación.
Porque un menú que no recoge nada no necesita banda de consentimiento, no tiene nada que filtrar y no tiene nada que explicar a un inspector. La verificación está al alcance de cualquiera: una sola petición al sitio muestra que no se devuelve ningún encabezado de cookie. Y la política de contenido de uno de los locales no permite absolutamente ningún recurso del exterior.
El carrito funciona en el navegador, como una lista que el cliente le muestra al camarero o usa para dividir la cuenta. Enviar el pedido a la cocina requiere una conexión al sistema del local y es un trabajo aparte, con verificación de compatibilidad previa. No llamamos «pedido online» a un carrito que no llega a ninguna parte.
Se puede construir, pero no la ponemos en marcha sin el acuerdo escrito del local, porque es una promesa que se honra en caja. Nuestra regla: las funciones que comprometen al local frente al cliente — descuentos, horarios de cocina, disponibilidades — no se publican sobre la base de una conversación verbal.
Tres: rumano como base, ruso e inglés. Completo significa categorías, nombres, volúmenes, composiciones, etiquetas de sabor y los textos de presentación, no solo los botones. Una verificación automática falla si el menú no está completo en los tres — por eso no llega al sitio a medias traducido.
Entre las verificaciones previas a la publicación hay una que exige que los precios bajen en cada categoría. No es una regla comercial, es un detector de errores de mecanografía: una posición introducida con una cifra de más o de menos rompe el orden y detiene la publicación. El resto de verificaciones se ocupan de fotografías faltantes y de archivos inválidos.
El resultado es una sola página generada, con las fuentes alojadas en el mismo dominio y sin recursos solicitados de dominios terceros. Eso significa menos conexiones que abrir y nada que esperar de un servicio externo. No publicamos cifras de velocidad medidas en otras condiciones que las tuyas.
Sí, y entonces la política de contenido de la página permite exactamente ese dominio, nada más. En uno de los dos locales eso se ve desde fuera. También vale la pena decir el reverso: en ese momento la página ya no es «sin nada de fuera», así que la decisión se toma de forma consciente, no como un extra.
Son dos sitios web con el mismo motor, del mismo propietario, y lo decimos explícitamente. La diferencia funcional declarada entre ellos son las recomendaciones de asociación por producto, que el segundo no tiene. Podríamos presentarlos como trabajos independientes; sería una exageración de portafolio.
Cuéntanos tu proceso. Juntos decidimos qué merece la pena construir, qué podemos conectar y cómo verificamos el resultado.