O Ramen Joe começou como um restaurante em Lisboa. Hoje são cinco casas, uma app iOS publicada na App Store, uma app Android publicada na Google Play, um programa de fidelização com Apple Wallet e Google Wallet, e um back-office que corre as operações do grupo. Tudo assente numa única plataforma.
Este artigo conta o que essa plataforma resolveu, o que custou construí-la em vez de comprar SaaS de prateleira, e onde é que a maioria dos grupos de restauração se enganam quando tentam fazer o mesmo.
Sumário executivo
Um grupo de restauração com mais de duas localizações tem, tipicamente, três problemas técnicos que ninguém dimensiona bem no início. Reservas fragmentadas por casa. Programa de fidelização que não segue o cliente entre lojas. Dados de operações que vivem em ficheiros locais e conversas de WhatsApp.
O Ramen Joe consolidou a operação num só sistema. Reservas partilhadas, cliente único, fidelização, cardápio digital, gestão de staff e análise centralizada. O resultado prático é que o cliente que carimba em Lisboa vê o mesmo saldo no Porto, enquanto a equipa administra cinco casas — e pode acrescentar novas localizações — a partir do mesmo back-office.
O custo desta escolha não é trivial. Mas o custo de não a fazer aparece mais tarde, disfarçado de churn, staff a repetir trabalho, e decisões de expansão tomadas às cegas.
O problema de negócio
Quando um restaurante único se torna um grupo, o software que servia bem para uma casa começa a partir. Não porque seja mau. Porque foi desenhado para um contexto que já não é o teu.
O sintoma clássico: cada localização acaba com o seu próprio módulo de reservas, muitas vezes ligado ao Google ou a uma ferramenta SaaS específica. Os clientes de fidelização vivem numa base de dados por casa, ou pior, num caderno físico. Quando queres saber quantos clientes recorrentes tens no grupo, não há resposta. Só há estimativas.
O ponto crítico é este. Numa casa só, o CRM é o gerente. Ele conhece os habituais, sabe quem prefere mesa ao fundo, sabe quem traz a família ao domingo. Em cinco casas, essa memória distribuída deixa de funcionar. E o cliente nota.
Porque é que isto importa
A fidelização 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 superior ao custo de trazer de volta um cliente existente. Isto é verdadeiro em quase todos os sectores, e a restauração não foge à regra.
Se o teu programa de fidelização não segue o cliente entre lojas, estás a tratar cada visita como se fosse a primeira. Não é. O cliente lembra-se. 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. Que horários enchem primeiro. Que dias da semana precisam de campanhas. Que localização tem mais no-shows. Sem plataforma única, esses dados existem, mas ninguém os consegue ler.
O que a plataforma faz
A arquitectura do Ramen Joe assenta em três blocos que conversam entre si. Um backend Express com base de dados relacional, um frontend Next.js público para clientes finais, e um conjunto de apps nativas (iOS SwiftUI e Android) que replicam a experiência do site em contexto móvel.
A escolha de ter apps nativas 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-se de forma limpa em apps nativas — o cartão de fidelização vai directo para a carteira do telefone, e recebe actualizações automáticas quando o saldo muda.
- Push notifications em iOS têm restrições que a web não permite contornar sem prejudicar a experiência.
- O tap-to-scan do staff em restaurantes precisa de câmara com autofocus rápido e latência quase zero. A web ainda perde aqui.
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 registo do cliente, o histórico, a preferência de mesa — tudo isso é global.
Cardápio digital e expansão sem dependência técnica
A plataforma também centraliza o cardápio digital das cinco localizações. A equipa gere produtos, informações e a configuração de cada casa no mesmo back-office, mantendo a experiência consistente no site e nas apps sem duplicar o trabalho por canal.
A gestão multilocalização foi desenhada para que a expansão do grupo não dependa de uma nova intervenção técnica. A própria equipa pode cadastrar uma localização, definir horários, contactos, cardápio, mesas, regras de reservas e restantes configurações operacionais.
Depois de configurada, a nova casa passa a estar disponível no site e nas aplicações móveis a partir da mesma fonte de dados. Não é necessário desenvolver uma nova versão do site ou das apps apenas para adicionar uma unidade. Isso reduz o custo e o tempo entre a decisão de expansão e a entrada da nova localização nos canais digitais.
Fidelização entre lojas: a decisão que muda tudo
O ponto de fricção mais comum em grupos de restauração é 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 a uma localização.
O Ramen Joe optou pelo oposto. Um só programa, uma só carteira de pontos, um só cliente. Isto tem implicações não triviais em contabilidade — quem "paga" pelo carimbo dado em Lisboa e resgatado no Porto? — mas resolve-se com regras internas de imputação, não com fragmentação do sistema.
O cliente não devia ter de pensar no assunto. E, na verdade, nem pensa. Instala a app uma vez, adiciona o cartão à Wallet, e a experiência é a mesma em qualquer casa do grupo. Isto é product-market fit de fidelização.
O papel do staff
Um sistema de fidelização digital só funciona se o staff colaborar. Se o processo de carimbo demorar mais que o processo antigo de dar um carimbo físico num cartão de papel, o staff sabota — não por má vontade, por sobrecarga em horas de pico.
O scanner do Ramen Joe foi desenhado com este constraint em mente. Um staff logado abre a app, aponta a câmara ao QR do cliente, e o carimbo é dado em menos de dois segundos. Sem menus, sem confirmações intermédias, sem digitação.
A permissão de dar carimbos está separada da permissão de aceder ao back-office. Um empregado de mesa carimba. Um gerente vê relatórios. Um administrador do grupo altera regras. Esta separação é banal em SaaS empresarial, mas é frequentemente ignorada em software de restauração — e depois pergunta-se porque é que houve fraude interna com pontos.
Reservas: menos automação, mais controlo
Há 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 num sábado à noite não devia ser confirmada automaticamente sem alguém olhar para a sala. Um pedido de mesa específica devia passar por alguém que conheça a casa. E as excepções de última hora precisam de humano.
A plataforma do Ramen Joe permite ambos os modelos, casa a casa. Reservas standard são automáticas. Reservas grandes ou com pedidos especiais entram numa fila de aprovação. E há um canal de SMS via Telnyx que envia lembretes uma hora antes da reserva, o que reduziu no-shows sem gerar spam.
O SMS é curto por design. 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.
As apps: iOS e Android lançadas em simultâneo
As versões para iOS e Android foram lançadas em simultâneo. A app Android ficou disponível mais tarde 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.
As duas aplicações foram desenvolvidas em paralelo, com a mesma proposta de valor: reservas, fidelização e uma experiência consistente nas duas plataformas. A diferença no momento em que ficaram visíveis nas lojas resultou apenas dos tempos de aprovação de cada marketplace.
O custo é evidente: dois codebases nativos em vez de um framework cross-platform como React Native ou Flutter. Foi um trade-off consciente. O ganho é uma app que se comporta como a plataforma pede, não como o denominador comum permite.
O que corre mal nestes projectos
A maioria dos grupos de restauração que tentam construir uma plataforma como esta cometem os mesmos três erros. Vale a pena nomeá-los.
- Começam pelo app. Sem backend maduro e sem regras de negócio claras, a app vira uma casca bonita que replica o caos operacional em ecrãs móveis.
- Confiam em plugins WordPress para reservas e fidelização. Funciona para uma casa. Parte para cinco.
- Contratam agências que constroem por projecto e desaparecem. O software não termina no launch. Começa lá.
O antídoto para os três é o mesmo. Trata o software como infraestrutura, não como campanha. Investe primeiro em fundações — backend, base 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. Isto elimina a categoria de bugs de "funciona no meu computador" e permite reverter em minutos se algo partir 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 ficheiros de tradução. Isto parece exagero para um restaurante em Lisboa, até perceberes que 30% dos clientes em zonas turísticas não falam português. E que expandir para uma cidade nova é mais fácil quando o sistema já suporta múltiplas línguas.
Terceiro: separar sandbox de produção com regras claras. O Ramen Joe tem uma versão sandbox que espelha produção mas com dados de teste. Qualquer alteração passa primeiro por lá. Isto reduz a probabilidade de partir uma reserva real ao testar uma feature nova.
Onde é que este modelo se aplica
A arquitectura do Ramen Joe não é específica de ramen. É aplicável a qualquer negócio de retalho ou hospitalidade com múltiplas localizações e uma base de clientes recorrentes. Grupos de restaurantes, cadeias de cafés, redes de barbearias, clínicas com várias unidades, ginásios com mais de um pólo.
O denominador comum é este: o cliente é um só, mas a operação é distribuída. Se o teu software não reflectir isso, estás a pagar em fricção operacional aquilo que devias estar a ganhar em fidelização.
Key takeaways
- Um grupo de restauração com múltiplas casas precisa de plataforma unificada — reservas fragmentadas custam mais do que o software para as consolidar.
- Uma plataforma verdadeiramente multilocalização permite cadastrar novas localizações, cardápios e regras operacionais sem pedir alterações técnicas no site ou nas apps.
- Fidelização entre lojas não é opcional se queres retenção real. O cliente não se importa em que casa gastou.
- Apps nativas justificam-se quando Wallet, push notifications e câmara rápida são parte central da experiência.
- O staff é utilizador do sistema tanto como o cliente. Se o fluxo demorar mais que o processo antigo, o sistema é sabotado por sobrecarga.
- Git como fonte única, sandbox separado de produção, e i18n desde o dia um. São decisões de fundação que evitam refactors caros mais tarde.
- O erro mais caro é começar pela app antes de ter o backend maduro.
O próximo passo natural para um grupo nesta fase não é adicionar mais features. É medir. Que carimbos convertem em segunda visita. Que casas retêm melhor. Que campanhas movem realmente a agulha. Uma plataforma unificada torna essa análise possível. Depois, é uma questão de olhar.