Nota para revisão: PeekingMe é uma startup própria, em fase de lançamento (peekingme.com.br). Como o produto ainda não tem histórico de uso público consolidado, este case fica mais curto na seção de Resultados e mais focado em arquitetura e decisões técnicas. Se já houver números de usuários, criadores ativos ou faturamento que possam ser divulgados no lançamento, me avisa que eu incluo.
Problema
Criadores de conteúdo que querem monetizar por assinatura geralmente dependem de plataformas de terceiros que ficam com uma fatia da receita, limitam a personalização da marca e colocam o criador em pé de igualdade com milhares de outros perfis na mesma plataforma. Para quem já tem audiência própria, isso significa abrir mão de identidade visual, domínio próprio e controle sobre a experiência de assinatura em troca de conveniência.
O problema que o PeekingMe resolve é dar a um criador a estrutura completa de um site de conteúdo por assinatura — cadastro, pagamento recorrente, entrega de conteúdo, recursos de IA — sem que ele precise construir nada disso do zero, mas com a marca do criador na frente, não a do produto.
Solução
Desenvolvi o PeekingMe como uma plataforma multi-tenant e white-label: cada criador que assina o serviço ganha, na prática, o próprio site de conteúdo por assinatura, com pagamentos integrados e recursos de IA, sem precisar lidar com a complexidade de infraestrutura, cobrança recorrente ou desenvolvimento por trás disso.
O termo "white-label" aqui é central para a decisão de arquitetura: o sistema precisa suportar múltiplos tenants (múltiplos criadores, cada um com seu próprio espaço de conteúdo, assinantes e configurações) enquanto apresenta uma experiência que parece pertencer exclusivamente àquele criador, não a uma plataforma genérica compartilhada.
Arquitetura
O backend é construído em Laravel, responsável pela lógica de negócio, autenticação, gestão de tenants e integração com o gateway de pagamento. O frontend é em React, consumindo a API do backend.
Multi-tenancy é o ponto que mais influencia as decisões de modelagem do sistema. Cada criador precisa de isolamento de dados (conteúdo, assinantes, configurações de cobrança de um criador não podem vazar para outro) e ao mesmo tempo o sistema precisa continuar operável em escala — não dá para tratar cada criador como uma instalação separada e independente, isso inviabilizaria manutenção e evolução do produto conforme a base de criadores cresce. A saída foi projetar o domínio pensando em tenant como dimensão de primeira classe em cada entidade relevante do sistema, em vez de tratar o isolamento como algo resolvido só na camada de infraestrutura.
Sendo "white-label", a camada de apresentação também precisa responder à identidade de cada criador: domínio, cores, nome, identidade visual. Isso é resolvido no React do lado do frontend, consumindo configuração de tenant vinda da API do Laravel, em vez de ter builds separados por criador — o mesmo código de frontend se adapta à configuração do tenant ativo.
A infraestrutura roda na AWS, o que dá a flexibilidade necessária para uma arquitetura multi-tenant escalar conforme o número de criadores na plataforma cresce, sem exigir provisionamento manual de servidor por tenant. Isso importa especialmente numa fase de lançamento, em que o número de criadores ativos pode crescer de forma imprevisível e a infraestrutura precisa acompanhar sem replanejamento constante.
Os pagamentos recorrentes (assinaturas) são processados via Asaas, gateway de pagamento brasileiro com suporte nativo a cobrança recorrente, PIX e boleto — uma escolha relevante para um produto voltado ao mercado brasileiro, onde meios de pagamento locais (especialmente PIX) têm papel importante na taxa de conversão de assinatura. Trabalhar com um gateway nacional também simplifica questões de compliance e de experiência de pagamento para o assinante final, que já está familiarizado com PIX e boleto.
Os recursos de IA da plataforma — que fazem parte da proposta de valor para o criador, dando a ele funcionalidades que normalmente exigiriam integração própria — são tratados como parte do backend Laravel, orquestrando chamadas a serviços externos e mantendo essa complexidade fora da camada de apresentação em React.
Por ser um produto próprio e ainda em lançamento, a arquitetura multi-tenant e os recursos de IA da plataforma continuam em evolução ativa — decisões de modelagem de dados e isolamento entre tenants foram tomadas pensando em suportar crescimento no número de criadores sem reescrever a base do sistema. Diferente de um projeto sob contrato com escopo fechado, o PeekingMe é iterado continuamente com base no que faz sentido para o produto evoluir.
Por que esse projeto é diferente dos outros
Vale marcar uma diferença em relação aos outros três cases: o PeekingMe é produto próprio, não projeto para cliente. Isso significa que as decisões técnicas aqui carregam também decisão de produto — que recursos de IA priorizar, que modelo de precificação faz sentido, que nível de customização oferecer no white-label. É o projeto onde atuo como desenvolvedor e como responsável pelas escolhas de escopo e prioridade ao mesmo tempo.
Stack
Laravel (backend, API, gestão multi-tenant), React (frontend), AWS (infraestrutura), Asaas (gateway de pagamento e assinaturas recorrentes).
Site: peekingme.com.br