Ramen Joe empezó como un restaurante en Lisboa. Hoy son cinco locales, una app iOS publicada en la App Store, una app Android publicada en Google Play, un programa de fidelización con Apple Wallet y Google Wallet, y un back-office que hace correr las operaciones del grupo. Todo apoyado en una única plataforma.
Este artículo cuenta qué resolvió esa plataforma, qué costó construirla en lugar de comprar SaaS de estantería, y dónde se equivoca la mayoría de los grupos de restauración cuando intentan hacer lo mismo.
Resumen ejecutivo
Un grupo de restauración con más de dos locales tiene, típicamente, tres problemas técnicos que nadie dimensiona bien al principio. Reservas fragmentadas por casa. Programa de fidelización que no sigue al cliente entre tiendas. Datos de operaciones que viven en ficheros locales y conversaciones de WhatsApp.
Ramen Joe consolidó la operación en un solo sistema. Reservas compartidas, cliente único, fidelización, carta digital, gestión de personal y análisis centralizado. El resultado práctico es que el cliente que sella en Lisboa ve el mismo saldo en Oporto, mientras el equipo administra cinco casas —y puede añadir nuevos locales— desde el mismo back-office.
El coste de esta elección no es trivial. Pero el coste de no hacerlo aparece más tarde, disfrazado de churn, personal que repite trabajo, y decisiones de expansión tomadas a ciegas.
El problema de negocio
Cuando un restaurante único se convierte en un grupo, el software que servía bien para una casa empieza a romperse. No porque sea malo. Porque fue diseñado para un contexto que ya no es el tuyo.
El síntoma clásico: cada local acaba con su propio módulo de reservas, muchas veces conectado a Google o a una herramienta SaaS específica. Los clientes de fidelización viven en una base de datos por casa, o peor, en un cuaderno físico. Cuando quieres saber cuántos clientes recurrentes tienes en el grupo, no hay respuesta. Solo hay estimaciones.
El punto crítico es este. En una sola casa, el CRM es el encargado. Él conoce a los habituales, sabe quién prefiere mesa al fondo, sabe quién trae a la familia el domingo. En cinco casas, esa memoria distribuida deja de funcionar. Y el cliente lo nota.
Por qué esto importa
La fidelización en restauración no es un detalle operativo. Es la columna vertebral del modelo. El coste de captación de un cliente nuevo es varias veces superior al coste de traer de vuelta a un cliente existente. Esto es cierto en casi todos los sectores, y la restauración no escapa a la regla.
Si tu programa de fidelización no sigue al cliente entre tiendas, estás tratando cada visita como si fuera la primera. No lo es. El cliente se acuerda. El sistema no.
El segundo ángulo es operativo. Un grupo con cinco casas genera datos suficientes para tomar decisiones de negocio informadas. Qué horarios se llenan primero. Qué días de la semana necesitan campañas. Qué local tiene más no-shows. Sin plataforma única, esos datos existen, pero nadie los consigue leer.
Qué hace la plataforma
La arquitectura de Ramen Joe se apoya en tres bloques que conversan entre sí. Un backend Express con base de datos relacional, un frontend Next.js público para clientes finales, y un conjunto de apps nativas (iOS SwiftUI y Android) que replican la experiencia del sitio en contexto móvil.
La elección de tener apps nativas en lugar de PWA merece explicación. No es vanidad técnica. Fue una decisión de producto motivada por tres cosas concretas.
- Apple Wallet y Google Wallet se integran de forma limpia en apps nativas: la tarjeta de fidelización va directa a la cartera del teléfono, y recibe actualizaciones automáticas cuando el saldo cambia.
- Las push notifications en iOS tienen restricciones que la web no permite sortear sin perjudicar la experiencia.
- El tap-to-scan del personal en restaurantes necesita cámara con autofocus rápido y latencia casi cero. La web todavía pierde aquí.
Del lado de las reservas, el sistema está desincronizado del calendario de cada casa. Cuando un cliente reserva en Lisboa, la mesa queda bloqueada solo en Lisboa. Pero el registro del cliente, el historial, la preferencia de mesa: todo eso es global.
Carta digital y expansión sin dependencia técnica
La plataforma también centraliza la carta digital de los cinco locales. El equipo gestiona productos, información y la configuración de cada casa en el mismo back-office, manteniendo la experiencia consistente en el sitio y en las apps sin duplicar el trabajo por canal.
La gestión multilocal fue diseñada para que la expansión del grupo no dependa de una nueva intervención técnica. El propio equipo puede dar de alta un local, definir horarios, contactos, carta, mesas, reglas de reservas y las demás configuraciones operativas.
Una vez configurada, la nueva casa pasa a estar disponible en el sitio y en las aplicaciones móviles desde la misma fuente de datos. No hace falta desarrollar una nueva versión del sitio o de las apps solo para añadir una unidad. Eso reduce el coste y el tiempo entre la decisión de expansión y la entrada del nuevo local en los canales digitales.
Fidelización entre tiendas: la decisión que cambia todo
El punto de fricción más común en grupos de restauración es este. Cada casa quiere tener su programa. Cada encargado quiere ver a sus clientes fidelizados. Y cada campaña de marketing tiende a quedar atada a un local.
Ramen Joe optó por lo contrario. Un solo programa, una sola cartera de puntos, un solo cliente. Esto tiene implicaciones no triviales en contabilidad —¿quién "paga" por el sello dado en Lisboa y canjeado en Oporto?— pero se resuelve con reglas internas de imputación, no con fragmentación del sistema.
El cliente no debería tener que pensar en el asunto. Y, en realidad, ni piensa. Instala la app una vez, añade la tarjeta al Wallet, y la experiencia es la misma en cualquier casa del grupo. Esto es product-market fit de fidelización.
El papel del personal
Un sistema de fidelización digital solo funciona si el personal colabora. Si el proceso de sellado tarda más que el proceso antiguo de dar un sello físico en una tarjeta de papel, el personal lo sabotea: no por mala voluntad, por sobrecarga en horas punta.
El escáner de Ramen Joe fue diseñado con esta restricción en mente. Un empleado logueado abre la app, apunta la cámara al QR del cliente, y el sello se registra en menos de dos segundos. Sin menús, sin confirmaciones intermedias, sin tecleo.
El permiso para dar sellos está separado del permiso para acceder al back-office. Un camarero sella. Un encargado ve informes. Un administrador del grupo cambia reglas. Esta separación es banal en SaaS empresarial, pero se ignora con frecuencia en software de restauración, y después uno se pregunta por qué hubo fraude interno con puntos.
Reservas: menos automatización, más control
Hay una tentación en cualquier sistema de reservas moderno: automatizarlo todo. Confirmación automática, recordatorio automático, respuesta automática a cambios. Y, en la mayoría de los casos, funciona bien.
En restauración de calidad, funciona peor. Una reserva de doce personas un sábado por la noche no debería confirmarse automáticamente sin que alguien mire la sala. Una petición de mesa específica debería pasar por alguien que conozca la casa. Y las excepciones de última hora necesitan humano.
La plataforma de Ramen Joe permite ambos modelos, casa por casa. Las reservas estándar son automáticas. Las reservas grandes o con peticiones especiales entran en una cola de aprobación. Y hay un canal de SMS vía Telnyx que envía recordatorios una hora antes de la reserva, lo que redujo los no-shows sin generar spam.
El SMS es corto por diseño. Nombre, hora, casa. Un enlace para cancelar. Nada más. El paquete comercial se dimensionó con una estimación inicial de 1.500 SMS al año, calculada a partir del volumen esperado de reservas. No es un límite técnico: la capacidad se puede ajustar según la operación crezca.
Las apps: iOS y Android lanzadas en simultáneo
Las versiones para iOS y Android se lanzaron a la vez. La app Android quedó disponible más tarde porque el proceso de revisión de Google Play tardó más, no por una decisión de escalonar el producto o privilegiar una plataforma.
Las dos aplicaciones se desarrollaron en paralelo, con la misma propuesta de valor: reservas, fidelización y una experiencia consistente en las dos plataformas. La diferencia en el momento en que se hicieron visibles en las tiendas fue solo consecuencia de los tiempos de aprobación de cada marketplace.
El coste es evidente: dos codebases nativos en lugar de un framework cross-platform como React Native o Flutter. Fue un trade-off consciente. La ganancia es una app que se comporta como la plataforma pide, no como el denominador común permite.
Qué sale mal en estos proyectos
La mayoría de los grupos de restauración que intentan construir una plataforma como esta cometen los mismos tres errores. Vale la pena nombrarlos.
- Empiezan por la app. Sin backend maduro y sin reglas de negocio claras, la app se convierte en una carcasa bonita que replica el caos operativo en pantallas móviles.
- Confían en plugins WordPress para reservas y fidelización. Funciona para una casa. Se rompe para cinco.
- Contratan agencias que construyen por proyecto y desaparecen. El software no termina en el lanzamiento. Ahí es donde empieza.
El antídoto para los tres es el mismo. Trata el software como infraestructura, no como campaña. Invierte primero en cimientos —backend, base de datos, autenticación, permisos, deploy continuo— y solo después en superficie visible.
Buenas prácticas que valieron la pena
Algunas decisiones parecen menores pero tuvieron un impacto desproporcionado en el funcionamiento del sistema en producción.
Primero: git como fuente única de verdad. Cada cambio pasa por commit, cada deploy es automático vía GitHub Actions. Esto elimina la categoría de bugs de "funciona en mi ordenador" y permite revertir en minutos si algo se rompe en producción. La documentación oficial de GitHub sobre continuous deployment cubre bien los principios.
Segundo: internacionalización en serio. El sitio funciona en portugués e inglés, con strings centralizadas en ficheros de traducción. Esto parece exagerado para un restaurante en Lisboa, hasta que te das cuenta de que el 30% de los clientes en zonas turísticas no habla portugués. Y que expandirse a una ciudad nueva es más fácil cuando el sistema ya soporta varios idiomas.
Tercero: separar sandbox de producción con reglas claras. Ramen Joe tiene una versión sandbox que refleja producción pero con datos de prueba. Cualquier cambio pasa primero por allí. Esto reduce la probabilidad de romper una reserva real al probar una funcionalidad nueva.
Dónde se aplica este modelo
La arquitectura de Ramen Joe no es específica del ramen. Es aplicable a cualquier negocio de retail u hostelería con varios locales y una base de clientes recurrentes. Grupos de restaurantes, cadenas de cafeterías, redes de barberías, clínicas con varias unidades, gimnasios con más de un centro.
El denominador común es este: el cliente es uno solo, pero la operación está distribuida. Si tu software no lo refleja, estás pagando en fricción operativa lo que deberías estar ganando en fidelización.
Ideas clave
- Un grupo de restauración con varias casas necesita una plataforma unificada: las reservas fragmentadas cuestan más que el software para consolidarlas.
- Una plataforma verdaderamente multilocal permite dar de alta nuevos locales, cartas y reglas operativas sin pedir cambios técnicos en el sitio o en las apps.
- La fidelización entre tiendas no es opcional si quieres retención real. Al cliente no le importa en qué casa gastó.
- Las apps nativas se justifican cuando Wallet, push notifications y cámara rápida son parte central de la experiencia.
- El personal es usuario del sistema tanto como el cliente. Si el flujo tarda más que el proceso antiguo, el sistema queda saboteado por sobrecarga.
- Git como fuente única, sandbox separado de producción, e i18n desde el día uno. Son decisiones de cimientos que evitan refactors caros más tarde.
- El error más caro es empezar por la app antes de tener el backend maduro.
El siguiente paso natural para un grupo en esta fase no es añadir más funcionalidades. Es medir. Qué sellos convierten en segunda visita. Qué casas retienen mejor. Qué campañas mueven de verdad la aguja. Una plataforma unificada hace posible ese análisis. Después, es cuestión de mirar.