O Ramen Joe começou como um restaurante em Lisboa. Hoje são cinco casas, um app iOS publicado na App Store, um app Android publicado na Google Play, um programa de fidelidade com Apple Wallet e Google Wallet, e um back-office que roda as operações do grupo. Tudo assentado em uma única plataforma.
Este texto conta o que essa plataforma resolveu, o que custou construí-la em vez de comprar SaaS de prateleira, e onde a maioria dos grupos de restaurantes erra quando tenta fazer o mesmo.
Resumo executivo
Um grupo de restaurantes com mais de duas unidades tem, normalmente, três problemas técnicos que ninguém dimensiona bem no começo. Reservas fragmentadas por casa. Programa de fidelidade que não segue o cliente entre lojas. Dados de operação que vivem em arquivos locais e conversas de WhatsApp.
O Ramen Joe consolidou a operação em um só sistema. Reservas compartilhadas, cliente único, fidelidade, cardápio digital, gestão de equipe e análise centralizada. O resultado prático é que o cliente que carimba em Lisboa vê o mesmo saldo no Porto, enquanto o time administra cinco casas — e pode acrescentar novas unidades — a partir do mesmo back-office.
O custo dessa escolha não é trivial. Mas o custo de não fazê-la aparece depois, disfarçado de churn, equipe repetindo trabalho e decisões de expansão tomadas às cegas.
O problema de negócio
Quando um restaurante único vira grupo, o software que servia bem para uma casa começa a rachar. Não porque seja ruim. Porque foi desenhado para um contexto que já não é o seu.
O sintoma clássico: cada unidade termina com o seu próprio módulo de reservas, muitas vezes ligado ao Google ou a uma ferramenta SaaS específica. Os clientes de fidelidade vivem em um banco de dados por casa, ou pior, em um caderno de papel. Quando você quer saber quantos clientes recorrentes tem no grupo, não existe resposta. Só existem estimativas.
O ponto crítico é este. Em uma casa só, o CRM é o gerente. Ele conhece os habituais, sabe quem prefere mesa no fundo, sabe quem leva a família no domingo. Em cinco casas, essa memória distribuída deixa de funcionar. E o cliente percebe.
Por que isso importa
A fidelidade em restauração não é um detalhe operacional. É a coluna vertebral do modelo. O custo de aquisição de um cliente novo é várias vezes maior que o custo de trazer de volta um cliente existente. Isso vale para quase todos os setores, e restaurante não é exceção.
Se o seu programa de fidelidade não segue o cliente entre lojas, você está tratando cada visita como se fosse a primeira. Não é. O cliente lembra. O sistema é que não.
O segundo ângulo é operacional. Um grupo com cinco casas gera dados suficientes para tomar decisões de negócio informadas. Quais horários enchem primeiro. Quais dias da semana precisam de campanha. Qual unidade tem mais no-shows. Sem uma plataforma única, esses dados existem, mas ninguém consegue ler.
O que a plataforma faz
A arquitetura do Ramen Joe se apoia em três blocos que conversam entre si. Um backend Express com banco de dados relacional, um frontend Next.js público para clientes finais, e um conjunto de apps nativos (iOS SwiftUI e Android) que replicam a experiência do site no contexto mobile.
A escolha de ter apps nativos em vez de PWA merece explicação. Não é vaidade técnica. Foi uma decisão de produto motivada por três coisas concretas.
- Apple Wallet e Google Wallet integram de forma limpa em apps nativos — o cartão de fidelidade vai direto para a carteira do celular e recebe atualização automática quando o saldo muda.
- Push notifications no iOS têm restrições que a web não consegue contornar sem prejudicar a experiência.
- O tap-to-scan da equipe em restaurante precisa de câmera com autofoco rápido e latência quase zero. A web ainda perde nisso.
Do lado das reservas, o sistema é dessincronizado do calendário de cada casa. Quando um cliente reserva em Lisboa, a mesa fica bloqueada apenas em Lisboa. Mas o registro do cliente, o histórico, a preferência de mesa — tudo isso é global.
Cardápio digital e expansão sem depender de time técnico
A plataforma também centraliza o cardápio digital das cinco unidades. O time gerencia produtos, informações e a configuração de cada casa no mesmo back-office, mantendo a experiência consistente no site e nos apps sem duplicar trabalho por canal.
A gestão multiunidade foi desenhada para que a expansão do grupo não dependa de uma nova intervenção técnica. O próprio time cadastra uma unidade, define horários, contatos, cardápio, mesas, regras de reservas e o resto das configurações operacionais.
Depois de configurada, a nova casa passa a estar disponível no site e nos apps a partir da mesma fonte de dados. Não precisa desenvolver uma nova versão do site ou dos apps só para adicionar uma unidade. Isso reduz o custo e o tempo entre a decisão de expansão e a entrada da nova unidade nos canais digitais.
Fidelidade entre lojas: a decisão que muda tudo
O ponto de atrito mais comum em grupos de restaurantes é este. Cada casa quer ter o seu programa. Cada gerente quer ver os seus clientes fidelizados. E cada campanha de marketing tende a ficar presa em uma unidade.
O Ramen Joe fez o oposto. Um só programa, uma só carteira de pontos, um só cliente. Isso tem implicações não triviais em contabilidade — quem "paga" pelo carimbo dado em Lisboa e resgatado no Porto? — mas se resolve com regras internas de rateio, não com fragmentação do sistema.
O cliente não deveria ter que pensar nisso. E, na prática, nem pensa. Instala o app uma vez, adiciona o cartão à Wallet, e a experiência é a mesma em qualquer casa do grupo. Isso é product-market fit de fidelidade.
O papel da equipe
Um sistema de fidelidade digital só funciona se a equipe colaborar. Se o processo de carimbo demorar mais que o antigo carimbo físico no cartão de papel, a equipe sabota — não por má vontade, por sobrecarga no horário de pico.
O scanner do Ramen Joe foi desenhado com essa restrição em mente. Um funcionário logado abre o app, aponta a câmera para o QR do cliente, e o carimbo sai em menos de dois segundos. Sem menus, sem confirmações intermediárias, sem digitação.
A permissão de dar carimbos está separada da permissão de acessar o back-office. Um garçom carimba. Um gerente vê relatórios. Um administrador do grupo altera regras. Essa separação é banal em SaaS corporativo, mas costuma ser ignorada em software de restaurante — e depois se pergunta por que houve fraude interna com pontos.
Reservas: menos automação, mais controle
Existe uma tentação em qualquer sistema de reservas moderno: automatizar tudo. Confirmação automática, lembrete automático, resposta automática a alterações. E, na maioria dos casos, funciona bem.
Em restauração de qualidade, funciona menos bem. Uma reserva de doze pessoas em um sábado à noite não deveria ser confirmada automaticamente sem alguém olhar para o salão. Um pedido de mesa específica deveria passar por alguém que conhece a casa. E as exceções de última hora precisam de humano.
A plataforma do Ramen Joe permite os dois modelos, casa a casa. Reservas padrão são automáticas. Reservas grandes ou com pedidos especiais entram em uma fila de aprovação. E há um canal de SMS via Telnyx que envia lembrete uma hora antes da reserva, o que reduziu no-shows sem gerar spam.
O SMS é curto de propósito. Nome, hora, casa. Um link para cancelar. Nada mais. O pacote comercial foi dimensionado com uma estimativa inicial de 1.500 SMS por ano, calculada a partir do volume esperado de reservas. Não é um limite técnico: a capacidade pode ser ajustada conforme a operação cresce.
Os apps: iOS e Android lançados em paralelo
As versões para iOS e Android foram lançadas em paralelo. O app Android ficou disponível um pouco depois porque o processo de revisão da Google Play demorou mais, não por uma decisão de fasear o produto ou privilegiar uma plataforma.
Os dois apps foram desenvolvidos em paralelo, com a mesma proposta de valor: reservas, fidelidade e uma experiência consistente nas duas plataformas. A diferença no momento em que apareceram nas lojas veio só do tempo de aprovação de cada marketplace.
O custo é evidente: duas codebases nativas em vez de um framework cross-platform como React Native ou Flutter. Foi um trade-off consciente. O ganho é um app que se comporta como a plataforma pede, não como o denominador comum permite.
O que dá errado nesses projetos
A maioria dos grupos de restaurantes que tentam construir uma plataforma como essa comete os mesmos três erros. Vale a pena nomear cada um.
- Começam pelo app. Sem backend maduro e sem regras de negócio claras, o app vira uma casca bonita que replica o caos operacional em telas mobile.
- Confiam em plugins de WordPress para reservas e fidelidade. Funciona para uma casa. Quebra em cinco.
- Contratam agências que constroem por projeto e somem. O software não termina no launch. Começa lá.
O antídoto para os três é o mesmo. Trate o software como infraestrutura, não como campanha. Invista primeiro em fundação — backend, banco de dados, autenticação, permissões, deploy contínuo — e só depois em superfície visível.
Boas práticas que valeram a pena
Algumas decisões parecem menores, mas tiveram impacto desproporcional no funcionamento do sistema em produção.
Primeiro: git como fonte única de verdade. Cada alteração passa por commit, cada deploy é automático via GitHub Actions. Isso elimina a categoria de bug de "funciona na minha máquina" e permite reverter em minutos se algo quebrar em produção. A documentação oficial do GitHub sobre continuous deployment cobre bem os princípios.
Segundo: internacionalização a sério. O site funciona em português e inglês, com strings centralizadas em arquivos de tradução. Parece exagero para um restaurante em Lisboa, até você perceber que 30% dos clientes em zonas turísticas não falam português. E que expandir para uma cidade nova fica mais fácil quando o sistema já suporta várias línguas.
Terceiro: separar sandbox de produção com regra clara. O Ramen Joe tem uma versão sandbox que espelha produção mas com dados de teste. Qualquer alteração passa primeiro por lá. Isso reduz a probabilidade de quebrar uma reserva real ao testar uma feature nova.
Onde esse modelo se aplica
A arquitetura do Ramen Joe não é específica de ramen. Vale para qualquer negócio de varejo ou hospitalidade com várias unidades e uma base de clientes recorrentes. Grupos de restaurantes, redes de cafés, redes de barbearias, clínicas com várias unidades, academias com mais de um polo.
O denominador comum é este: o cliente é um só, mas a operação é distribuída. Se o seu software não refletir isso, você está pagando em atrito operacional aquilo que deveria estar ganhando em fidelidade.
Key takeaways
- Um grupo de restaurantes com várias casas precisa de plataforma unificada — reservas fragmentadas custam mais do que o software para consolidá-las.
- Uma plataforma de fato multiunidade permite cadastrar novas unidades, cardápios e regras operacionais sem pedir alteração técnica no site ou nos apps.
- Fidelidade entre lojas não é opcional se você quer retenção real. O cliente não liga em qual casa gastou.
- Apps nativos se justificam quando Wallet, push notifications e câmera rápida são parte central da experiência.
- A equipe é usuária do sistema tanto quanto o cliente. Se o fluxo demorar mais que o processo antigo, o sistema é sabotado por sobrecarga.
- Git como fonte única, sandbox separado da produção e i18n desde o dia um. São decisões de fundação que evitam refactor caro depois.
- O erro mais caro é começar pelo app antes de ter o backend maduro.
O próximo passo natural para um grupo nessa fase não é acrescentar mais features. É medir. Quais carimbos convertem em segunda visita. Quais casas retêm melhor. Quais campanhas realmente movem o ponteiro. Uma plataforma unificada torna essa análise possível. Depois, é uma questão de olhar.