Construindo o Promobet

Agora que voltei a dedicar meu tempo livre ao desenvolvimento do Promobet, uma das coisas que mais me deixou satisfeito foi perceber que a estrutura e a arquitetura que definimos anteriormente continuam fazendo bastante sentido.

Os padrões que escolhemos, a separação de responsabilidades e as configurações do projeto estão, de certa forma, mais claras agora do que quando foram implementadas. Existe também um fator importante nisso: como eu sou o responsável pelo código, o contexto do projeto é muito mais compreensível para mim. Consigo voltar para uma parte da aplicação depois de algum tempo e ainda entender por que determinadas decisões foram tomadas.

E isso está começando a me levar a uma conclusão interessante: talvez já seja o momento de começar a documentar o projeto de verdade.

Não apenas uma documentação superficial sobre como executar a aplicação, mas uma documentação dos diferentes módulos, fluxos e responsabilidades — tanto no lado do cliente quanto no servidor.

A ideia é que essa documentação cresça junto com a própria implementação.

A separação clara entre camadas que fomos reforçando durante o desenvolvimento deve ajudar bastante nisso. Quando responsabilidades estão realmente separadas, documentá-las também se torna mais simples. Cada módulo possui um propósito mais claro, cada fluxo possui um lugar mais definido e as relações entre eles começam a formar uma espécie de mapa da aplicação.

Até agora, estou bastante satisfeito com o resultado.

É claro que ainda existem diversas pequenas interações que precisam ser refinadas. Existem ações disparadas pelo usuário, ações disparadas pelo próprio sistema e aqueles pequenos detalhes de UX que parecem insignificantes isoladamente, mas que fazem uma diferença enorme quando alguém realmente utiliza a aplicação.

A boa notícia é que a estrutura que temos hoje já possui os componentes e as abstrações necessárias para absorver essas mudanças sem precisar desmontar tudo novamente.

Quando o catálogo começa a ter um propósito

Uma das partes que mais evoluiu recentemente foi o sistema de ingestão e verificação de produtos.

Agora os usuários do sistema podem importar apenas produtos que sejam realmente alcançáveis pelas fontes que utilizamos. Isso parece uma regra simples, mas acabou se tornando uma parte importante da proposta do Promobet.

A plataforma não deveria simplesmente aceitar qualquer produto fornecido por um usuário e colocá-lo no catálogo.

Ela precisa também funcionar como uma camada de verificação.

O valor desse processo não está apenas em dizer se um produto possui determinados campos ou se o formato dos dados está correto. O ponto mais importante é manter o catálogo sanitizado de produtos que já não estão disponíveis ou que não podem mais ser alcançados.

Isso muda um pouco a forma como penso sobre o catálogo.

Ele deixa de ser apenas um lugar onde produtos são armazenados e passa a funcionar como uma espécie de camada de confiança entre a fonte dos produtos e a experiência final do usuário.

Também existem algumas extensões interessantes planejadas para isso.

Uma delas é introduzir algum tipo de aviso temporal nos itens do catálogo. Assim, um tenant poderia saber que determinado produto precisa ser verificado novamente sem necessariamente precisar fazer todo o processo de upload novamente.

Isso pode ser especialmente útil para quem depende de provedores de afiliados, onde links e disponibilidade podem mudar com frequência.

Ao mesmo tempo, para usuários que trabalham com links proprietários ou produtos que já pertencem a eles, esses avisos poderiam ser desabilitados. Se o usuário já controla a origem daquele produto, não faz muito sentido obrigá-lo a receber o mesmo tipo de alerta.

Ainda assim, a possibilidade de verificar novamente um item registrado continuaria disponível.

Dessa forma, conseguimos cobrir os dois cenários sem obrigar todos os usuários a seguirem exatamente o mesmo fluxo.

A arquitetura começa a virar produto

Estou terminando atualmente a TenantCatalogInterface, conectando-a aos sistemas de ingestão que já havíamos testado anteriormente e incorporando o módulo de verificação.

Isso também começou a deixar mais claro algo que, no início, era mais difícil de enxergar.

Boa parte do trabalho de backend não existe apenas para "fazer funcionar". Existe para controlar recursos.

Produtos vêm de fontes externas. Essas fontes podem mudar. Usuários podem importar grandes quantidades de dados. Verificações podem consumir recursos. E, conforme a plataforma cresce, essas operações precisam ser administradas.

Foi justamente por isso que começamos a estruturar melhor os serviços, os adapters, os enrichers, os transformers e os validators.

A separação não é apenas uma questão estética de arquitetura.

Ela permite que cada parte do processo seja observada, alterada e escalada de forma relativamente independente.

E, conforme o produto começa a tomar forma, essa separação também começa a refletir as próprias regras de negócio.

O modelo de negócio é uma parte do problema técnico

Existe uma decisão importante por trás do Promobet que influencia diretamente a arquitetura.

A ideia é que a plataforma seja sustentada por assinaturas.

Não quero construir o modelo em torno de dividir comissões ou porcentagens das vendas realizadas pelos tenants.

Isso cria um problema interessante.

Se o negócio depender exclusivamente de cobrar uma assinatura fixa dos tenants, existe um limite natural para o quanto cada cliente pode representar financeiramente para a plataforma.

Por isso, começamos a pensar em limites e caps que façam sentido em relação ao uso.

A lógica é relativamente simples: se um tenant possui uma grande audiência e utiliza intensamente a experiência, existe valor econômico nessa utilização e a plataforma precisa ser capaz de capturar uma parte desse valor através do próprio modelo de assinatura.

Isso também ajuda a definir quem realmente deveria ser o público-alvo.

Não estou necessariamente pensando em alguém que simplesmente quer colocar alguns produtos em uma página.

O cenário mais interessante é encontrar pessoas, criadores ou organizações que já possuem uma audiência agregada — comunidades, portais, fan bases, influenciadores ou outros canais com usuários recorrentes.

O tenant traz a audiência.

A plataforma fornece a experiência.

Os produtos fornecem o incentivo.

E, idealmente, todo mundo ganha alguma coisa com isso.

A ideia de um "anti-cassino"

Talvez essa seja uma das partes mais estranhas do projeto.

Desde o começo, uma das perguntas que me acompanha é:

Como usar a mesma linguagem de uma experiência de cassino sem construir um cassino?

Existe uma linguagem visual muito específica nesse tipo de produto.

Existem gatilhos.

Existem recompensas.

Existem expectativas.

Existem ciclos de interação.

Existe toda uma psicologia construída ao redor da sensação de descoberta, surpresa e antecipação.

E eu queria entender se seria possível utilizar parte dessa linguagem para construir algo que apontasse na direção oposta.

Em vez de uma experiência na qual a casa sempre ganha, a ideia seria criar uma experiência onde o incentivo está relacionado à descoberta de produtos e oportunidades reais.

O usuário participa.

O tenant oferece produtos.

Se os produtos forem bons, a audiência se envolve.

Se a audiência se envolve, os produtos podem gerar vendas.

O tenant ganha.

A plataforma ganha.

A audiência encontra algo que realmente queria.

Não deveria ser um jogo em que a única forma de alguém ganhar é outra pessoa perder.

Foi essa ideia que comecei a chamar, mentalmente, de um anti-cassino.

Não sei se o termo sobreviverá ao projeto.

Talvez nem seja uma boa definição.

Mas gosto da pergunta que ele representa.

Como aproveitar mecanismos de engajamento que já foram extremamente bem estudados sem necessariamente reproduzir o mesmo modelo de exploração que normalmente acompanha esses mecanismos?

É uma aspiração, obviamente.

Nada disso é garantido.

E existe uma quantidade enorme de coisas que ainda precisam ser feitas

O projeto ainda está longe de estar completo.

Ainda existem lacunas importantes.

As opções avançadas dos usuários precisam ser finalizadas. Por exemplo, usuários devem poder excluir suas contas, mas uma conta com uma assinatura ativa precisará primeiro passar pelo processo de cancelamento.

Também precisamos de um fluxo para reportar bugs e conteúdo inadequado.

A integração com o Stripe ainda precisa ser concluída, incluindo sua relação com os schemas de tenant e usuário, além do ciclo de vida das assinaturas — criação, manutenção e cancelamento.

E isso é apenas uma parte.

Existem também inúmeras pequenas decisões de UX, validações, estados intermediários, mensagens de erro e situações inesperadas que só aparecem quando começamos a utilizar o sistema de verdade.

Esse é provavelmente um dos aspectos mais interessantes de construir algo assim.

A arquitetura pode estar bem organizada.

Os componentes podem estar bem definidos.

Os serviços podem estar separados.

Mas o produto continua encontrando novas perguntas.

Construir também é uma forma de descobrir

Uma das coisas que mais me agradam ao voltar para esse projeto é perceber que o conhecimento adquirido ao longo do desenvolvimento não possui exatamente um preço.

Aprender como determinados serviços funcionam.

Entender melhor as limitações de uma API.

Descobrir como estruturar uma pipeline de ingestão.

Pensar sobre cache, validação, limites, autenticação, autorização e persistência.

Perceber onde uma abstração realmente ajuda e onde ela apenas adiciona complexidade.

Tudo isso vai se acumulando.

E, quando volto para o código depois de algum tempo, consigo enxergar algumas dessas decisões de uma maneira diferente.

Isso também me fez pensar bastante sobre o estado atual do desenvolvimento de software.

Especialmente agora, com toda a explosão em torno de agentes, frameworks agentic e sistemas capazes de gerar grandes quantidades de código.

A pergunta que fica para mim é:

Tudo aquilo que podemos construir deveria necessariamente ser construído?

Independentemente do custo?

Independentemente do que perdemos no processo?

Existe algo estranho na quantidade de produtos, abstrações e estruturas que estamos sendo incentivados a produzir.

Temos LLMs que já conseguem nos ajudar com co-coding, reflexão arquitetural, debugging e exploração de soluções.

E, ao mesmo tempo, estamos construindo cada vez mais sistemas cujo propósito parece ser criar ainda mais sistemas.

Às vezes isso me parece quase um ouroboros — uma serpente mordendo a própria cauda.

Construímos ferramentas para construir mais ferramentas.

Que constroem outras ferramentas.

Que ajudam a construir mais software.

E, em algum momento, precisamos parar e perguntar se aquilo que estamos produzindo realmente precisa existir.

Talvez esse seja um dos maiores desafios da engenharia de software daqui para frente.

Não apenas aprender a construir mais rápido.

Mas aprender quando não construir.

De volta ao laboratório

Apesar de todas essas perguntas, existe uma coisa que permanece bastante simples:

Eu ainda quero ver até onde esse projeto consegue chegar.

Talvez dê certo.

Talvez não.

Talvez o Promobet se torne um produto real.

Talvez ele acabe sendo uma experiência que me ajude a chegar ao próximo trabalho que estou procurando, justamente por ter me colocado diante dos desafios que eu queria enfrentar.

Talvez eu nem consiga terminar.

E, nesse caso, ele ainda terá sido um pedaço importante da minha vida — um momento em que eu tive motivação suficiente para colocar uma quantidade enorme de mim mesmo em alguma coisa sem saber exatamente o que viria depois.

Não existe um caminho fácil.

Uma vez ouvi uma frase que dizia que a única maneira de saber que você está no caminho certo é quando o caminho à sua frente desaparece.

Na época, eu não entendi muito bem.

Hoje entendo um pouco melhor.

Como poderia existir um caminho à frente se é você quem está abrindo o caminho?

Talvez seja por isso que não faça tanto sentido se sentir perdido quando não conseguimos enxergar o que vem depois.

Se estamos construindo alguma coisa de verdade, talvez seja inevitável não saber exatamente para onde ela vai.

Então, se você também estiver passando por isso, talvez não precise se preocupar tanto com a sensação de estar perdido.

Talvez seja apenas o resultado de estar abrindo o próprio caminho.

Ainda existe muito trabalho pela frente.

Mas voltar para esse projeto já foi, por si só, bastante satisfatório.

E tudo que aprendi construindo essas estruturas, experimentando essas ferramentas e enfrentando esses problemas já tem valor — independentemente do que acontecer com o produto no final.

Então é isso.

De volta ao laboratório.