Plataforma de eventosGlint2026
Venda, portaria, relacionamento e reembolso rodam sozinhos dentro da regra. A fila só pede decisão humana no que saiu dela.
- Cliente

- Papel
- Product builder: descoberta, design e desenvolvimento com IA
- Duração
- Cerca de 3 semanas (junho de 2026)
- Disciplinas
- Estratégia de produto, UX/UI, Design system, Regras de negócio

O contexto
Quem organiza evento no Brasil trabalha com uma colcha de retalhos: uma ferramenta vende, outra faz o check-in, a planilha guarda os custos e o certificado é montado à mão. O dado de quem esteve ali fica espalhado e some.
O Glint nasceu para costurar isso num produto só. O organizador cria o evento, publica uma página de vendas, recebe pelo Stripe, emite o ingresso com QR, faz o credenciamento, conversa com o público e resolve o pós-venda. O participante, o operador da portaria, o expositor e o afiliado têm cada um o seu acesso.
A ideia que atravessa o produto é simples. O que tem regra clara roda sozinho: lotação, leitura do QR, estorno dentro do prazo, tag de comportamento. O que sai da regra vira uma fila para o organizador decidir.
A dor
Olhando para o fluxo de quem produz evento, os problemas mais caros não estavam na venda em si. Estavam nas bordas, onde o trabalho é manual:
- Lotação que não bate com o espaço físico. Vender ingresso por tipo sem amarrar à área real (pista, mezanino, camarote) abre espaço para vender mais lugares do que existem.
- Ingresso válido compartilhado. Um print do QR circula num grupo e duas pessoas tentam entrar com o mesmo código.
- Participante que vira um nome numa planilha. Quem comprou em três edições, visitou um estande e deu nota 10 aparece como três registros soltos.
- Reembolso por e-mail. O direito de arrependimento existe (7 dias pelo CDC), mas o processo é manual, lento e cheio de atrito para os dois lados.
Numa análise comparativa com concorrentes do mercado, o reembolso self-service apareceu como a maior lacuna do Glint. Foi uma das frentes priorizadas depois.
O estudo
Antes de desenhar, eu separei o evento em camadas de modelo, porque a interface depende de o modelo estar certo:
- Evento → Setor → Tipo de ingresso → Lote. Setor é a área física, com capacidade. Tipo é a condição comercial (inteira, meia, passe de um dia). Lote é a escada de preço, que vira por data, por percentual vendido ou por esgotamento.
- Uma pessoa, uma linha do tempo. Toda interação (compra, check-in, retirada de produto, visita a estande, avaliação, mensagem, tag) vira um evento na história daquela pessoa.
- Núcleo e extras. O que todo organizador precisa (evento, ingresso, checkout, check-in, financeiro) é núcleo e nunca fica bloqueado. O resto entra por plano.
Cada funcionalidade virou uma ficha de produto no repositório, com objetivo, critérios de aceite, cenários felizes e não felizes e riscos. O catálogo tem um documento mestre e 21 fichas, e serviu de contrato entre design, código e teste.
A solução
Página de vendas com setores de verdade
A página pública agrupa os ingressos por setor e mostra o lote vigente de cada um. Quando um setor lota, a página diz isso com todas as letras e oferece a lista de espera.

O checkout é curto: dados do comprador, resumo, cupom e pagamento pelo Stripe. O preço é sempre recalculado no servidor, então alterar o valor no navegador não muda nada.

Capacidade rígida, travada na configuração
A decisão mais importante dos setores foi onde colocar a trava. A primeira versão bloqueava no checkout. Funcionava, mas confundia as métricas: o painel mostrava lotes com vagas num setor que já não tinha espaço.
A trava mudou de lugar e passou para a configuração. A soma dos lotes de todos os tipos de um setor não pode passar da capacidade dele, e reduzir a capacidade abaixo do que já está configurado é recusado. Com isso, o número que o organizador vê é o número que existe. A reserva por lote cuida do resto na hora da compra, sem ninguém contar lugar.

QR rotativo: opt-in, e por um bom motivo
Para o ingresso compartilhado, o QR pode girar. A cada 30 segundos o código muda, assinado pelo servidor, e a portaria aceita só a janela atual e a vizinha. Um print deixa de valer em menos de um minuto. Quando o evento usa QR rotativo, o código fixo antigo é recusado na leitura.
O custo é real: o celular do participante precisa de internet na portaria para o QR atualizar. Local com sinal ruim e QR rotativo ligado é fila na certa. Por isso a opção é desligada por padrão e o organizador liga evento a evento, com o aviso escrito na própria tela. Se a conexão cai, o app mantém o último código em vez de mostrar erro.

Já o ingresso reembolsado morre no servidor, com ou sem QR rotativo: toda leitura recusa o código cancelado. Na web não dá para impedir um print, então a defesa fica na leitura.
Pós-venda conforme o CDC, sem e-mail
Dentro do prazo, o participante pede o reembolso no app e o estorno sai na hora, direto no Stripe. Fora do prazo, o pedido vira uma solicitação para o organizador aprovar ou recusar. Upgrade de categoria fica liberado sempre (paga a diferença). Downgrade, só dentro da janela (recebe a diferença). O organizador define prazo, limite antes do evento e retenção.

Aqui a parte invisível pesou mais que a tela. Uma revisão adversarial encontrou o risco de estorno duplicado sob cliques simultâneos. A correção foi garantir que o item é cancelado primeiro, de forma atômica, e só então o dinheiro volta, com chave de idempotência no Stripe.

CRM 360° e o portal do expositor
Cada participante tem um perfil com gasto total, eventos, check-ins, retiradas e uma linha do tempo única. As tags são aplicadas sozinhas pelo comportamento: “Visitou: Lumen Labs” quando o crachá é lido no estande, “Comprou no estande” quando a compra sai de um produto vinculado a ele. Ninguém marca participante na mão.
Há também um painel de privacidade (LGPD) em que o titular vê, exporta ou anonimiza os seus dados, preservando o registro financeiro.

O expositor entra no próprio portal por código no e-mail e captura o lead lendo o QR do crachá.
Vender fora do Glint
Três widgets embarcáveis levam a venda para o site do organizador: carrinho de ingressos, carrinho de produtos e chat flutuante com o assistente de vendas. O botão de comprar abre a página do evento com o carrinho já montado, então o widget reaproveita todo o checkout em vez de duplicá-lo.

Visão do evento e planos
O painel do evento se adapta à fase (planejamento, pré-venda, véspera, dia do evento, pós) e mostra orçamento, conversão, lotação, check-ins e resultado.

O modelo comercial tem três planos. O básico é gratuito e cobre o núcleo inteiro. Os pagos liberam widgets, estandes, automações, NPS, bot de IA e afiliados. A trava mora no servidor, e o menu só esconde o que o plano não tem. Se o pagamento da assinatura falha, a conta volta para o básico: o organizador perde os extras, mas nunca o evento que está vendendo.
Como foi construído
É um monólito modular: NestJS com módulos por domínio, React com Vite, PostgreSQL, Redis e Stripe, com interface em português, inglês e espanhol. Eu fiz produto, design e código com IA. As entregas grandes foram quebradas em ondas executadas por vários agentes em paralelo, com revisões adversariais nas partes que mexem com dinheiro e segurança.
O design system escuro por padrão tem cerca de 17 componentes e foi aplicado a umas 50 telas. A suíte automatizada passou de mil testes, incluindo isolamento entre organizadores.
O que mudou
Para quem produz evento, o trabalho muda de natureza. Deixa de ser conferir e responder, e passa a ser decidir exceção.
O que era feito na mão. Vender ingresso por tipo sem amarrar à área física, lidar na porta com o print de um ingresso compartilhado, juntar o participante a partir de planilhas soltas e responder pedido de reembolso por e-mail.
O que ficou automático. A lotação travada na configuração, o QR que gira e recusa o print, o estorno dentro do prazo direto no Stripe, a tag de comportamento aplicada na leitura do crachá e a linha do tempo única de cada participante.
Onde a pessoa decide. O organizador liga o QR rotativo evento a evento, com o custo escrito ao lado do interruptor. Define prazo, limite e retenção do reembolso. E aprova ou recusa, na fila, só o pedido que saiu da regra.
O que eu levo desse projeto
As decisões que mais pesaram quase não aparecem na interface. Mudar a trava de capacidade do checkout para a configuração não criou tela nova, mas fez o número do painel voltar a significar alguma coisa. Deixar o QR rotativo desligado por padrão, com o custo escrito ao lado do interruptor, é mais honesto do que vender segurança sem falar da fila na portaria.
Também ficou claro que, num produto que mexe com dinheiro, o caminho feliz é a parte fácil. O trabalho está em perguntar o que acontece com dois cliques ao mesmo tempo, com o print de um ingresso reembolsado ou com o celular sem sinal na porta do evento.
