Emais Network
Plataforma de uma rede de networking empresarial presencial: venda de ingressos, clube de membros, grupos por cidade e financeiro por franquia. No ar com pagamentos reais desde maio de 2026.
- Papel
- Arquitetura (multi-tenant, autenticação, pagamentos) e metade do desenvolvimento, em dupla com o sócio
- Estúdio
- No ar desde
- 28/05/2026
- Código
- Privado (cliente)
Números
Contado no repositório em 22/09/2026, no estado de 16/09 (1.496 testes unitários e 828 de integração, contados por it(; 27 de Playwright). As franquias são os hosts do Caddyfile que respondem no ar. Dos 778 commits, 412 são meus. Número de membros e volume financeiro ficam de fora de propósito: a fonte real é banco de produção com dado pessoal.
O problema
A Emais Network organiza empresários em grupos que se encontram presencialmente para trocar indicações comerciais. A operação inteira vivia em ferramentas avulsas: ingresso vendido por serviço externo, presença conferida na porta e indicação registrada em papel — o dado que é o produto da rede era justamente o que não sobrevivia ao fim do evento.
Somava-se um requisito de crescimento: a rede pretendia abrir outras cidades, e cada franquia precisa enxergar o seu próprio financeiro e os seus próprios membros, sem nunca esbarrar nos da outra.
O que faz
- Eventos com venda de ingressos online: lotes com preço crescente, Pix, cartão à vista ou parcelado, cupons e cadastro do comprador dentro do próprio fluxo de compra.
- Portaria digital: check-in por leitura de QR, lista de presença e venda de última hora, numa conta operacional restrita a essa tela.
- Clube de membros em ciclos de quatro meses, à vista, parcelado ou por cobrança recorrente, com aviso automático de renovação.
- Grupos por cidade montados com apoio de IA, que evita colocar concorrentes diretos no mesmo grupo, com capitão e pedidos de troca.
- Métricas de networking e ranking: cada membro registra negócios fechados, faturamento gerado, contatos e cafés; a plataforma monta o placar de membros e de grupos.
- Financeiro por franquia e consolidado da rede: receita, custos, provisões, tabela de repasse, extrato conciliado com o banco e emissão de NFS-e, com visibilidade diferente por nível de usuário.
Como foi construído
Monorepo pnpm com um único app Next.js 15 servindo API e interface, PostgreSQL 16 via Prisma, autenticação com Auth.js, e os pontos caros — pagamento, e-mail, IA e fiscal — atrás de interfaces trocáveis. Roda num VPS com Docker Compose, Caddy à frente.
Quem separa as franquias é o banco, não o programador
Cada franquia é um inquilino, e o isolamento usa Row-Level Security do PostgreSQL: a aplicação conecta com um usuário sem privilégio de bypass e toda requisição abre a transação declarando de quem é o dado. Ou seja, o filtro não depende de alguém lembrar de escrever a cláusula certa em cada consulta — quem recusa é o banco.
O desenho é deliberadamente fail-closed: sem inquilino declarado, a consulta não devolve nada. O pior caso de um bug vira "não estou vendo os meus dados", nunca "estou vendo os dados da outra franquia". O preço aceito foi manter uma segunda conexão administrativa, proibida em código que atende requisição, para os poucos fluxos legitimamente entre inquilinos — webhook de pagamento e tarefas agendadas.
Stack
Aplicação
Dados
Integrações
Infra e testes
Telas
As telas públicas (evento e checkout) são do site em produção, sem login. As telas de administração vêm de um ambiente local isolado com banco semeado por dados fictícios (nomes inventados, e-mails @exemplo.com); nenhum dado de membro real aparece aqui.