ProLoot
Conceito, identidade e produto para um novo modelo de apostas baseado em habilidade real: o usuário compete valendo dinheiro com base no próprio desempenho.
Contexto
E se você pudesse apostar em si mesmo?
Sempre tive uma relação próxima com jogos competitivos. A lógica de evolução, a ideia de que resultado está diretamente ligado a habilidade: isso sempre me interessou mais do que depender de resultado externo.
Com o tempo, percebi um contraste claro com o mercado de apostas tradicional: o usuário não tem controle sobre o que está apostando. Você não joga, você assiste. O ProLoot nasceu da pergunta: e se o jogador pudesse competir valendo dinheiro com base no próprio desempenho?
O projeto foi desenvolvido junto com meu irmão, com complementaridade técnica e envolvimento direto com o problema desde o início.
Problema
A infraestrutura não existe. O desafio começa aí.
Não existe uma forma simples, confiável e escalável de usuários competirem entre si valendo dinheiro com base em desempenho real. Os obstáculos não eram de interface: eram estruturais.
Exploração
Dados primeiro. Interface depois.
A decisão foi não projetar interface antes de entender o que era tecnicamente possível. Sem dados confiáveis, qualquer fluxo seria construído sobre uma hipótese inválida.
- →Steam: permite autenticação via OAuth, mas não fornece dados granulares de partida. Insuficiente para validação de desempenho.
- →APIs da Riot (Valorant, LoL): boa cobertura de dados, mas acesso comercial restrito e dependente de aprovação.
- →APIs de outros jogos competitivos: cada plataforma tem suas próprias regras. Não existe padrão entre elas.
O insight mais importante do projeto: a viabilidade depende mais da qualidade dos dados do que da qualidade da interface. UX não resolve problema de infraestrutura. Tentar fazer isso é desperdiçar tempo no lugar errado.
Meu papel
Conceito, identidade e produto
Fui responsável pela concepção do modelo, pela identidade visual e pelo design do produto:
- →Definição do conceito e da hipótese de negócio
- →Criação da identidade visual completa: logo, paleta, estética e linguagem
- →Estruturação das regras de negócio e dos fluxos do produto
- →Análise técnica de viabilidade com APIs externas
- →Construção do MVP junto com meu irmão
Aprendizados
O que esse projeto me ensinou
- →Validação técnica antes de design. Em produtos com dependência de dados externos, a arquitetura precisa ser provada antes da interface.
- →Confiança é o produto em sistemas financeiros. A percepção de segurança não é detalhe. É o motivo pelo qual o usuário fica.
- →Limitações técnicas definem o produto, não a ambição. O escopo real é determinado pelo que as APIs permitem, não pelo que você quer construir.
- →UX não resolve tudo. Há problemas que precisam de solução técnica antes de qualquer decisão de design.
- →Proximidade com o problema acelera decisão. Trabalhar com alguém que também vive o contexto elimina ciclos longos de validação.