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 foi o que mais me puxou.
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. Ele assiste o resultado acontecer nas mãos de outra pessoa. O ProLoot nasceu da pergunta: e se o jogador pudesse competir valendo dinheiro com base no próprio desempenho?
O projeto foi concebido e validado junto com meu irmão, com complementaridade técnica e envolvimento direto com o problema desde o início.
Antes de partir pra construção, testamos a demanda. Uma landing com lista de beta trouxe mais de 3 mil cadastros, a maior parte via tráfego pago, com um CPL em torno de R$2,50. A intenção do público estava provada antes de qualquer decisão técnica.
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 eram estruturais, ligados a dados e validação, muito antes de qualquer questão de interface.
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 da qualidade dos dados, e essa base precisa estar de pé antes de qualquer decisão de interface. Desenhar antes disso é 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
- →Validação de demanda: landing de beta, tráfego pago e leitura de CPL
- →Análise técnica de viabilidade com APIs externas
- →Validação do conceito e da viabilidade 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 é o que faz o usuário ficar e depositar.
- →Limitações técnicas definem o produto. O escopo real é determinado pelo que as APIs permitem, dentro do que dá pra construir de fato.
- →Alguns problemas são técnicos antes de serem de design. Há questões que precisam de solução de arquitetura antes de qualquer decisão de interface.
- →Proximidade com o problema acelera decisão. Trabalhar com alguém que também vive o contexto elimina ciclos longos de validação.