Nos últimos dias eu fiz uma coisa que, olhando de fora, parece pequena: criei uma aplicação web para um bolão da Copa dentro da comunidade do Guaxinil.
A ideia era simples.
A galera entra com a conta do Discord, faz os palpites dos jogos, tenta prever a classificação dos grupos, acompanha o ranking e disputa alguns prêmios simbólicos: uma chave de jogo da Steam para o primeiro colocado e um mês de Discord Nitro para o segundo.
Nada muito corporativo. Nada com escopo gigante. Nada que precise virar startup.
Só uma ideia divertida para a comunidade.
Mas, como quase sempre acontece quando a gente constrói alguma coisa de verdade, o projeto foi ficando mais interessante justamente quando deixou de ser “só uma tela com palpites”.
O produto começa quando a brincadeira precisa funcionar
No começo, a ideia parecia ser apenas:
“Vamos fazer um bolão para a comunidade.”
Mas logo começaram a aparecer decisões que mudam bastante a experiência:
Como evitar que qualquer pessoa de fora participe?
Como identificar corretamente cada jogador?
Como validar que o usuário faz parte do servidor do Discord?
Como organizar os jogos da Copa de forma coerente?
Como separar palpites de placar, grupos e mata-mata?
Como deixar o ranking divertido, mas sem virar bagunça visual?
Como transformar uma brincadeira em uma experiência que parece pertencer à comunidade?
Esse é o tipo de coisa que eu gosto em projetos pequenos: eles expõem decisões reais sem o peso de uma operação enorme.
A aplicação não precisava ser complexa. Mas precisava ter cuidado.
A stack foi simples, mas intencional
Usei uma stack que já faz parte do meu fluxo de trabalho:
Next.js
TypeScript
Tailwind CSS
Shadcn/UI
Prisma
PostgreSQL
Auth.js/NextAuth
Discord OAuth
Motion para algumas interações
A parte técnica mais interessante foi integrar o login com Discord e restringir o acesso apenas para membros do servidor Guaxinil.
A autenticação por si só resolveria só metade do problema. Qualquer pessoa poderia logar com Discord. O que eu precisava era de uma regra mais próxima do contexto real:
“Você só participa se fizer parte da toca.”
Então o fluxo ficou mais ou menos assim:
O usuário entra com Discord.
A aplicação salva os dados principais do perfil.
O sistema verifica se ele faz parte do servidor do Guaxinil.
Se fizer, libera o acesso.
Se não fizer, mostra uma tela de acesso restrito com convite para entrar na comunidade.
Parece detalhe, mas muda bastante a percepção de produto.
A aplicação deixa de ser apenas uma página pública e passa a funcionar como uma extensão da própria comunidade.
O ranking virou parte da experiência
Uma das partes mais divertidas foi transformar o ranking em algo com cara de “evento da toca”.
Não queria uma tabela fria, com nome e pontos.
A ideia era que o ranking tivesse um pouco de identidade visual, quase como figurinhas ou cards colecionáveis. Por isso os primeiros colocados ganharam cards especiais, com avatar do Discord, posição, pontuação, acertos e aquele exagero visual controlado que combina com comunidade gamer.
Esse tipo de detalhe não é obrigatório tecnicamente, mas faz diferença emocionalmente.
Porque, no fim, o ranking não é só uma lista.
É onde a zoeira acontece.
É onde alguém vai printar que está em primeiro.
É onde alguém vai reclamar que perdeu ponto por apostar com clubismo.
É onde a comunidade começa a interagir com o produto.
E isso é muito mais interessante do que simplesmente “exibir dados”.
O desafio dos dados da Copa
Outro ponto técnico curioso foi lidar com os jogos da Copa.
Minha primeira pergunta foi: existe uma API oficial, simples e gratuita para consumir os jogos?
A resposta prática foi: não do jeito ideal.
Então optei por uma abordagem mais controlada: estruturar os dados em arquivos JSON, importar para o banco e deixar a aplicação preparada para trabalhar com jogos, grupos, seleções, mata-mata e resultados.
Isso me deu mais controle e evitou transformar um projeto de comunidade em uma dependência frágil de API externa.
Para o contexto do bolão, fazia muito mais sentido ter:
dados base importados;
resultados atualizados de forma controlada;
ranking calculado internamente;
regras claras de pontuação.
É uma decisão simples, mas importante: nem toda automação vale o custo de complexidade que adiciona.
Uma brincadeira também exige produto
O que mais me chamou atenção nesse projeto foi perceber que até uma aplicação pequena passa pelas mesmas camadas de produto que projetos maiores.
Tem usuário.
Tem contexto.
Tem regra de negócio.
Tem autenticação.
Tem permissão.
Tem dados.
Tem experiência visual.
Tem comunicação.
Tem comunidade.
E talvez esse seja o insight principal: produto não começa quando o projeto é grande. Produto começa quando alguém precisa usar aquilo de verdade.
Mesmo que seja só um bolão.
Mesmo que seja uma brincadeira.
Mesmo que o prêmio seja uma chave de jogo e um mês de Nitro.
A diferença está em tratar a experiência com cuidado.
O Guaxinil como laboratório de ideias
O mais legal é que o Guaxinil tem se tornado um espaço onde essas ideias podem acontecer de forma leve.
É uma comunidade para trocar ideia, jogar, estudar, compartilhar coisas, testar projetos, rir de escolhas duvidosas e, de vez em quando, transformar uma piada interna em uma aplicação funcional.
Esse bolão nasceu exatamente desse tipo de ambiente.
Não veio de uma demanda formal. Veio de uma vontade de criar algo para a galera usar.
E isso me lembrou uma coisa importante: nem todo projeto precisa nascer com uma grande pretensão. Às vezes, construir algo pequeno para pessoas reais já é suficiente para aprender muito.
Se você quiser fazer parte do Guaxinil, trocar ideia com a gente, jogar, estudar, acompanhar os projetos e participar dessas maluquices organizadas, o convite está aqui:
A toca está aberta.
Compartilhar em:
Sem spam. Só conteúdo que vale abrir.