O Royal Riders BH é um clube de motociclistas de Belo Horizonte reunido em torno das motos Royal Enfield. O clube organiza passeios com roteiro, ponto de encontro e vagas limitadas, mantém um quadro de associados e registra a participação de quem anda junto. A BeeGo construiu a plataforma que sustenta essa operação: um site em WordPress que cuida de cadastro, eventos e ingressos, e um aplicativo que acompanha o associado desde a reserva até o check-in na estrada.
O ponto de partida
Não havia sistema anterior a resgatar. O clube funcionava como a maioria dos clubes funciona: listas de presença em grupos de mensagem, confirmações soltas e um controle de associados que vivia em planilha. Isso dá conta enquanto o grupo é pequeno. Quando os passeios passam a ter vagas limitadas, pagamento, briefing e registro de presença, cada saída vira um trabalho manual de conferência.
O projeto nasceu, então, como construção, e com uma restrição clara desde o início: o público do clube não é um público de aplicativo. É gente que entrou para andar de moto, com idade média mais alta, sem paciência para cadastro longo nem para interface cheia de opções. Toda decisão de produto foi tomada em cima disso.
A base: WordPress como sistema de operação
O lado administrativo foi construído em WordPress, mas não como site institucional. O WordPress ali é o sistema onde a operação do clube acontece. Os passeios são produtos com data, vaga e valor; o calendário de eventos guarda roteiro, briefing em PDF e as informações de cada saída; o ingresso de cada participante é um registro próprio, com os dados que o clube precisa ter na mão no dia (moto, placa, contato de emergência).
Em volta disso foi escrito código dedicado, em vez de empilhar plugins de catálogo. O cadastro de associado, as reservas de passeio, o check-in, a lista de membros, o controle de entregas e as mensagens automáticas são plugins próprios, feitos para as regras deste clube. Uma dessas regras aparece em quase todo fluxo: o clube aceita quem anda em outra marca, mas associado Royal Enfield e convidado de outra marca não passam pelos mesmos caminhos. Isso é código, não configuração.
Há um detalhe de operação que resume bem o projeto: um pedido pago não quer dizer que a pessoa foi ao passeio. O fluxo tem um estado próprio para presença confirmada, separado do estado de pagamento, porque é essa informação que alimenta o histórico de quem roda com o clube.
O aplicativo: o passeio na mão do associado
Sobre essa base foi construído um aplicativo que o associado instala no celular, feito em React e publicado de forma automática a cada atualização. O login tem três etapas curtas, o cadastro usa máscaras em todos os campos e a tela inicial mostra apenas o que interessa naquele momento.
A peça mais usada é o modo de passeio. Ele liga sozinho dezoito horas antes da saída e fica no ar até o fim do dia. Nele o associado vê a contagem regressiva para o encontro, abre a navegação até o ponto de partida, confirma presença e faz o check-in por geolocalização quando chega. Para o clube, isso substitui a conferência manual: a presença entra no sistema no momento em que acontece, com coordenada e hora.
Passeio concluído, o associado recebe o badge daquela data. A gamificação é simples de propósito e cumpre a função de dar memória ao histórico de quem anda com o clube.
O momento crítico: um cabeçalho que desaparecia
O aplicativo conversa com o site por uma API REST própria. A autenticação foi desenhada para ser leve: cada token de associado é gravado de forma indexada, de modo que validar uma chamada seja uma consulta direta, e não uma varredura de usuários.
Funcionou no desenvolvimento e quebrou em produção. As chamadas autenticadas chegavam ao servidor sem o cabeçalho de autorização, e o associado caía de volta para a tela de login. A camada de hospedagem removia o cabeçalho antes de o WordPress ver a requisição, e esse comportamento não estava sob nosso controle.
A solução foi deixar de depender de um caminho único. O token passou a ser aceito por três vias diferentes, com o aplicativo enviando por todas, e a validação foi plugada em duas camadas da autenticação do WordPress, para cobrir tanto a identificação do usuário quanto o bloqueio de requisições não autorizadas. Desde então o login do aplicativo deixou de ser um ponto frágil.
O mesmo cuidado valeu para a reserva. A compra do ingresso acontece no site, não dentro do aplicativo, e pedir para a pessoa fazer login outra vez no meio do caminho era perder a reserva. O aplicativo gera um link de uso único, válido por um minuto, que abre o checkout já autenticado; ao terminar, a pessoa encontra um botão para voltar ao aplicativo. Para o associado, é um toque.
Integrações
A plataforma se conecta ao que o clube usa para operar e para se comunicar:
- plataforma de e-mail transacional (Brevo), para confirmações, avisos de passeio e mensagens do clube;
- gateway de SMS, para o aviso que precisa chegar mesmo sem internet;
- serviço de geocodificação, para transformar a coordenada do check-in em endereço legível;
- grupos de mensagem do clube, com filtro por perfil de associado.
O envio por SMS rendeu um aprendizado que vale registrar: no Brasil, mensagem transacional por rota comum tem entrega irregular, e a diferença entre o aviso chegar ou não chegar está na escolha da rota, não no código.
Infraestrutura e sustentação
Site e aplicativo rodam na mesma hospedagem, com publicação automática a partir do repositório de código. A BeeGo responde pelo conjunto: banco, plugins próprios, API, aplicativo e as rotinas que mantêm o clube informado. O calendário de passeios não espera. Quando a data está marcada, a plataforma precisa estar de pé na véspera, no dia e durante a estrada.
O que a parceria entrega
O clube saiu de um controle manual por listas para uma operação em que reserva, pagamento, presença e histórico ficam no mesmo lugar. A conferência de presença deixou de ser um trabalho posterior ao passeio, porque o registro acontece no instante do check-in. E o associado não precisou aprender nada além de abrir o aplicativo no dia da saída.
É esse o tipo de trabalho que a BeeGo busca: assumir a responsabilidade técnica por uma operação que não pode parar e evoluir junto com ela.
Precisa transformar um processo manual em plataforma, com aplicativo, integrações e sustentação? Fale com a BeeGo.