O que o produto cobre
Um kartódromo é uma operação com frota, agenda e fila de gente no balcão. A plataforma foi construída em volta desse ciclo inteiro, não em volta do formulário de reserva:
- Painel administrativo do kartódromo: frota e karts, histórico de manutenção, traçados, campeonatos e sessões, e as pessoas que pilotam.
- Experiência do piloto no web e no mobile: perfil, histórico, reservas e o app usado no dia da corrida.
- Agenda e reservas, com sessões rental modeladas separadamente das baterias de campeonato, porque as duas se comportam de forma diferente.
- Check-in operacional no balcão, com QR code e boarding pass para o piloto.
- Race control: bloquear um piloto e registrar um incidente, para conduzir a sessão enquanto ela acontece.
- Dashboard financeiro para o dono do kartódromo.
- Camada de segurança das contas de equipe: MFA por TOTP, rate limiting, audit log e timeout de sessão.
- Agente no WhatsApp, adicionado depois, para as perguntas que chegam por mensagem em vez de por tela.
Como está montado
Um monorepo Turborepo, porque web e mobile são o mesmo produto em superfícies diferentes e as
regras precisam ser escritas uma vez. apps/web é a aplicação Next.js 15 com App
Router (painel administrativo, portal do piloto e landing), apps/mobile é o app em
Expo Router para iOS e Android, packages/api guarda os routers tRPC com a lógica de
negócio e packages/db guarda o schema e o client do Prisma.
Qual parte é minha
Construído com mais um desenvolvedor. A minha parte foi os cadastros, o fluxo de reserva, o app mobile e a camada de segurança:
- Cadastros: o fluxo inteiro, do formulário ao registro do qual uma grade de campeonato ou uma reserva é montada, incluindo o código do piloto, a categoria e os dados que o kartódromo guarda.
- Reservas, tanto para as sessões rental quanto para as baterias de campeonato.
- O app mobile, o lado em Expo e React Native usado no dia da corrida, incluindo login por biometria.
- A camada de segurança: MFA por TOTP, rate limiting, audit log e timeout de sessão.
Decisões técnicas e trade-offs
- tRPC com Zod em vez de um contrato REST escrito à mão. Os dois clientes chamam os mesmos procedures e herdam os tipos deles, então web e mobile não se desencontram. Trade-off: não existe superfície de API pública, então um terceiro precisaria de uma construída para ele.
- Supabase para identidade e Postgres, Prisma para o schema. Um provedor para auth e dados, com o schema como código e as migrations no repositório. Trade-off: a camada de dados fica dependente de um fornecedor, e o Prisma entra entre as queries e o banco.
- Login por biometria no mobile, Google OAuth e e-mail no web. A equipe no balcão abre um navegador; o piloto abre um app com a digital. Mesma identidade, duas entradas.
- Testes de aceitação com Playwright contra um Supabase real em vez de mocks. Trade-off: mais pesado e mais lento que teste unitário, mas exercita os fluxos do jeito que o kartódromo usa.
- Docker Compose para o ambiente local (Supabase e web), para nós dois rodarmos o mesmo ambiente em vez de dois parecidos.
Onde está
A plataforma está publicada na Vercel com GitHub Actions e soma cerca de 400 commits entre nós dois. Cronometragem e resultados ao vivo são as partes que ainda estão no roadmap; o resto da operação roda no que foi entregue.