Aplicación web
GNAMMM: el menú digital que se convierte en la gestión del restaurante
Plataforma SaaS multiinquilino para restaurantes: el cliente abre el menú escaneando un QR, el dueño gobierna la carta, los pedidos, las reservas y los clientes, y el camarero toma el pedido en la mesa con un terminal que lo imprime.
-
restaurantes activos
-
servicios en producción
-
tablas, una sola base de datos
-
×
más rápida la analítica de pedidos
En resumen
En breve
- GNAMMM da a un restaurante tres cosas conectadas entre sí: el menú digital que el cliente abre escaneando un QR, la gestión de la carta, los pedidos, las reservas y los clientes, y el terminal que pone la misma sala en la mano del camarero.
- Cada local tiene sus propios colores, tipografía, bordes y fondos, cargados al vuelo desde el tema guardado en la base de datos: dos restaurantes con el mismo código no se parecen en nada.
- Diez servicios en producción, nueve en Google Cloud Run más la aplicación Android, que comparten una sola base de datos MySQL de 62 tablas.
- El menú público lo sirve una API de solo lectura, con HTML completo para los motores de búsqueda y sitemap generado desde la base de datos.
- En producción desde 2025 en 19 restaurantes, crecida pieza a pieza y sin una sola ventana de mantenimiento.
Un PDF online no le hace ganar nada a nadie
En 2024 el menú con QR ya era algo común: decenas de servicios convertían un PDF en una página web. La cuestión es que un PDF online no le trae un euro más a un restaurante. No dice qué platos se miran y no se piden, no recoge un contacto, no toma una reserva, no manda un ticket a la cocina.
GNAMMM parte del menú, lo único que el cliente abre por su cuenta sin instalar nada, y lo usa como puerta de entrada a los datos: cada escaneo es un cliente que entra en el sistema. Es una decisión que marcó la arquitectura antes de la primera línea de código, porque el menú tiene que ser rapidísimo y público mientras la gestión tiene que ser rica y protegida. Con el tiempo se convirtieron en dos backends distintos.
El mismo código, un aspecto para cada local
El menú del cliente es una aplicación web en React e Ionic, servida como PWA. El recorrido es QR, página, menú: una aplicación que hubiera que instalar habría parado al cliente en el primer paso.
La parte que importa no es la lista de platos, es la personalización. Colores, tipografía, radio de los bordes, fondos y disposición llegan al cargar desde el tema guardado en la base de datos, así que dos restaurantes en el mismo dominio no se parecen. Aquí al lado está exactamente el mismo código con tres temas distintos: un restaurante de pescado, una hamburguesería y un local nocturno.
Del menú al pedido, a la reserva, a la opinión
La ficha de producto no es una línea de tarifa: lleva la foto, los alérgenos con sus iconos, los añadidos configurables como rellenos, toppings y variantes de tamaño, las etiquetas tipo más vendido y el botón de añadir al carrito, cuando el local ha activado los pedidos.
Desde el mismo menú el cliente pide en la mesa, para llevar o a domicilio, reserva una mesa y deja una opinión. Tres recorridos que en la gestión se convirtieron después en tres secciones enteras, con un carrito que guarda también las notas de cada plato.
La gestión del dueño
El panel está en Next.js 15 con TypeScript y Tailwind: unos doscientos hooks, uno por cada operación de la API, y unas cincuenta áreas funcionales. La página de inicio es un cuadro de analítica con pedidos, facturación, clientes únicos y la comparación entre todos los locales del mismo propietario, porque muchos clientes tienen más de un restaurante.
Productos, menús, categorías y añadidos se reordenan arrastrándolos, con filtros por disponibilidad y existencias y un sistema de características (vegano, picante, sin gluten, casero) que cuenta 24 entradas comunes más las del local concreto. Al lado están el tablero de pedidos de tres columnas dividido por canal, las salas con sus mesas, las reservas en calendario, el programa de fidelidad, los datos de los clientes y los mensajes por WhatsApp Business.
El editor del tema, con vista previa viva
Es la pantalla de la que estoy más orgulloso. El dueño cambia el color de la marca, la tipografía, el radio de los bordes y los fondos, y ve el resultado mientras lo cambia, dentro de un móvil simulado en la misma página. Nada de guardar a ciegas, nada de recargar la página y ver cómo ha quedado.
El tema no es una hoja de estilos escrita a mano para cada cliente: son valores en la base de datos que el menú lee al arrancar. Por eso un local cambia de cara sin que nadie tenga que publicar una versión nueva.
Un menú en React que Google puede leer
Una página construida en JavaScript es invisible para la mitad de los programas que indexan la web. Aquí la solución es el dynamic rendering: nginx reconoce el programa que está pidiendo la página y lo manda a un endpoint en Python que devuelve HTML completo, con título, descripción, Open Graph y datos estructurados del restaurante, del menú y de los horarios. Las personas siguen recibiendo la aplicación web.
El archivo robots.txt y el sitemap se generan desde la base de datos: un restaurante nuevo entra en el sitemap por sí solo, sin reconstruir nada, y quedan fuera los locales sin productos, los que están en construcción y los desactivados. Hay también una página pública que reúne todos los locales de la plataforma y se filtra por ciudad.
Primero medir, después reescribir
En el verano de 2026 la gestión se había vuelto lenta, y la petición natural habría sido reescribir el backend. Antes de escribir una línea medí la infraestructura, y el cuadro era otro: el backend funcionaba con un solo proceso de trabajo síncrono mientras la plataforma le mandaba hasta 80 peticiones a la vez, la base de datos era la instancia más pequeña disponible, compartida por cinco servicios y además en otra región, y ningún servicio tenía instancias siempre encendidas.
Una vez arreglada la configuración del servidor de aplicaciones, dos procesos con ocho hilos cada uno, y reducido el número de conexiones a la base de datos para no mover la cola de un sitio a otro, diez peticiones en paralelo pasaron de 879 a 352 milisegundos. Solo en ese momento reescribí, y tampoco todo de golpe: un segundo backend FastAPI al lado del de Flask, con las rutas movidas de un recurso a la vez, primero las lecturas y por último las escrituras. Un mapa que dice qué backend sirve qué recurso, en un solo archivo del frontend, permite mover un recurso, o devolverlo atrás, cambiando una línea. La analítica de pedidos de un año pasó de 110 segundos a medio segundo: no por un algoritmo más listo, sino porque una cadena de consultas anidadas se convirtió en un número fijo de agregaciones.
El tiempo real, sin un segundo almacén de datos
Un tablero de pedidos que se actualiza por intervalos significa tickets vistos con medio minuto de retraso. En la gestión había tres intentos de tiempo real abandonados: un trozo de código que apuntaba a un endpoint que nunca se escribió, un cliente comentado y un servidor que con un proceso síncrono no habría funcionado igualmente. Los quité todos e hice uno que funciona, con Server Sent Events en el backend FastAPI, donde una conexión abierta es una rutina suspendida y no un proceso bloqueado.
Las decisiones menos obvias son dos. Nada de segundo almacén de datos: una base de datos dedicada al tiempo real habría significado una doble escritura que puede perder pedidos y un segundo sistema de autenticación que mantener alineado. Y el flujo no transporta los datos, solo avisa de que algo ha cambiado: la lista sigue siendo la única fuente de verdad, así un mensaje perdido no deja la página en un estado incoherente. Para las reservas, que no tenían una columna con la fecha de modificación, el cambio se reconoce por una firma calculada sobre estado, comensales, mesa y hora.
El terminal que imprime el ticket en la mesa
El último capítulo es hardware. Los dueños pedían algo que el navegador no puede dar: tomar el pedido en la mesa e imprimirlo al momento, incluso con el wifi que va y viene. El terminal es una aplicación Kotlin con Jetpack Compose para un equipo industrial con impresora térmica de 58 milímetros, NFC y lector de códigos. El fabricante no facilita herramientas de desarrollo, así que la forma de hablar con la impresora se reconstruyó a partir del programa del sistema.
La aplicación lee solo de la base de datos que lleva a bordo y deja que la red la actualice en segundo plano, así el camarero nunca espera una respuesta del servidor. Los pedidos creados y los cambios de estado van a una cola de salida y parten cuando vuelve la línea, con una clave que evita los duplicados si la respuesta se pierde por el camino. Los terminales están repartidos por los locales, así que una versión nueva se la descargan e instalan ellos solos.
Diez servicios, una sola base de datos
Hoy la plataforma está hecha de un backend Flask que escribe, cuatro servicios FastAPI que sirven el menú público, la gestión con su tiempo real, el panel de administración y la traducción de los menús con un modelo de lenguaje, un microservicio para los mensajes de WhatsApp, tres interfaces, la aplicación Android y la web de marketing en WordPress, mantenida fuera de la nube a propósito, para que marketing pueda cambiar una frase sin una publicación.
La decisión más discutida es la base de datos única, y es deliberada: con diez servicios y un equipo mínimo, diez bases de datos habrían significado diez copias de la misma tabla que mantener alineadas. El precio es que un cambio de esquema toca cinco servicios a la vez, así que las reglas son estrictas: columnas siempre compatibles con el pasado y un orden de publicación obligado, primero el esquema, después los servicios, al final las interfaces. El desarrollo en local, en cambio, sigue siendo un solo comando: un Makefile levanta la conexión a la base de datos, cinco backends y tres frontends en puertos fijos, incluso en varias sesiones de trabajo a la vez en la misma máquina.
El paquete
Qué se entregó
- Arquitectura de la plataforma, del monolito a diez servicios
- Menú digital PWA con tema a medida de cada local
- Gestión en Next.js con unas cincuenta áreas funcionales
- Dos API de lectura y un backend de escritura, migrados en caliente
- Aplicación Android para terminal, con impresión del ticket y cola de salida
- Panel de administración y traducción de los menús con IA
- Dynamic rendering, sitemap dinámico y datos estructurados
- Web de marketing en WordPress
En detalle
Ficha técnica
- Plataforma: SaaS multiinquilino en Google Cloud Run
- Año: 2025
- Estado: En producción
- Tecnologías: Python, FastAPI, Flask, Next.js, React, TypeScript, Kotlin, MySQL, Google Cloud, Web App
Las pantallas vienen de los sistemas en producción: los datos de la gestión son de una cuenta de demostración, los menús son los públicos de los locales activos. Cifras tomadas en octubre de 2026.
Hablemos
¿Necesitas un software así?
Si tienes un proceso que hoy gestionas a mano y querrías automatizar, cuéntamelo: vemos juntos si tiene sentido construir una herramienta encima.
¿Necesitas algo parecido? Este proyecto es un ejemplo de desarrollo de aplicaciones web y sistemas de gestión a medida. La primera reunión y el presupuesto son gratuitos: escríbeme y lo hablamos.
