Laboratório
KartPOA
Em desenvolvimentoPlataforma para pilotos amadores de kart fecharem baterias sem depender de grupo de WhatsApp: vagas, mínimo para confirmar, lista de espera e avisos automáticos. MVP construído, ainda não publicado.
1 de 5
Contexto
Bateria de kart de aluguel só sai se juntar gente suficiente. Na Grande Porto Alegre, o mercado em que o projeto começa, isso se combina em grupo de WhatsApp: alguém pergunta quem vai, as confirmações se misturam com o resto da conversa, e o organizador passa a semana contando nomes para saber se fecha o mínimo.
O KartPOA é um produto próprio do laboratório, gratuito para quem usa, com dois lados: quem organiza a bateria e quem quer correr. O kartódromo entra só como cadastro.
O problema
No grupo, ninguém sabe ao certo se a bateria já deu o mínimo. Quando lota e alguém desiste na véspera, a vaga vai para quem viu a mensagem primeiro, não para quem tinha pedido antes. E quando a bateria cai, parte do grupo só descobre ao chegar no kartódromo.
Enquete e formulário não resolvem: contam respostas, mas não sabem o que é mínimo, lotação ou fila, e não avisam ninguém quando a situação muda.
O que construímos
O organizador marca a corrida: kartódromo do catálogo, data e largada, mínimo de pilotos para confirmar e lotação máxima. A corrida entra no grid da semana, filtrável por cidade e por kartódromo. O piloto vê as vagas e quanto falta para o mínimo, se inscreve e compartilha no WhatsApp um link com o texto pronto, "faltam X pilotos pra rolar".
Com a corrida lotada, quem chega depois entra na lista de espera e vê sua posição. Quando um confirmado desiste, o primeiro da fila sobe e é avisado. O sistema avisa sozinho quando a corrida confirma, quando abre vaga e quando é cancelada. Quem não tem conta vê quantos estão inscritos, não quem.
Decisões técnicas
Status calculado da contagem, nunca digitado
O banco guarda só se a corrida está aberta ou cancelada. Confirmada, lotada e encerrada são calculadas a cada leitura, a partir de inscritos, mínimo, lotação e horário: o que a tela mostra não diverge de quem está inscrito, e não existe rotina de atualização que possa falhar.
Avisos gravados junto com a ação
Inscrição, desistência e cancelamento gravam o evento de aviso na mesma transação. Um processo de fundo transforma os eventos em notificações sem duplicar e tenta de novo até cinco vezes; depois disso, o evento fica marcado como falho. O "vai rolar" sai uma vez por corrida, mesmo que o grid caia e volte ao mínimo.
A última vaga não estoura
A inscrição roda em transação serializável, com um lugar por piloto garantido pelo banco: dois pilotos tentando a última vaga ao mesmo tempo não ficam os dois confirmados. Quem garante a lotação é a transação, não a tela.
Dado de piloto só para quem precisa
Os nomes do grid aparecem só para quem está logado; link compartilhado, título e prévia da corrida levam apenas dado público. O piloto exporta em JSON tudo o que o sistema guarda dele e exclui a conta em definitivo, e as rotas de "meus dados" não têm identificador na URL para trocar.
Resultado e estado atual
O MVP está construído e roda de ponta a ponta em ambiente local, com as mesmas imagens Docker preparadas para o deploy: marcar corrida, grid com filtros, inscrição, lista de espera com promoção, cancelamento, avisos no app, exportação e exclusão de dados. Ainda não foi publicado e não tem usuários. O nome é provisório.
Faltam a tela de edição de perfil, a recuperação de senha por e-mail e o deploy, e a fila ainda não anda em dois casos de borda: quando o organizador aumenta a lotação e quando um confirmado exclui a conta. As telas desta página usam dados de demonstração: kartódromos e pilotos são fictícios.
Stack
- TypeScript
- NestJS
- Next.js
- PostgreSQL
- Prisma
- OpenAPI
Alguma coisa sua depende de juntar gente?
Se uma atividade só acontece com gente suficiente e tudo se combina numa conversa de grupo, com confirmação contada à mão e aviso que não chega, vale uma conversa de 30 minutos.




