ClubePro

O texto longo da página do produto. Escrito para quem compra para revender.

---

O problema que você vai vender resolvendo

Barbearia, petshop, lavanderia, cafeteria e estúdio vivem de fluxo imprevisível. Dezembro salva o ano, fevereiro assusta, e nenhum deles sabe na segunda-feira quanto vai entrar na sexta.

A saída que esse mercado já descobriu sozinho é a assinatura: "4 cortes por mês por R$ 120", "banho + tosa por R$ 200", "café ilimitado por R$ 90". Quem tenta, funciona. O problema não é a ideia, é o controle.

Hoje esse controle é um caderno atrás do balcão, uma planilha que só o dono entende, ou um grupo de WhatsApp. E o dinheiro vaza em três lugares, sempre os mesmos:

1. A cobrança que não sai. Ninguém lembra de cobrar o mês de quem faltou.
2. O benefício resgatado a mais. O cliente diz que ainda tem dois cortes. Tinha um. Ninguém vai discutir com o cliente na frente da loja.
3. O assinante que cancelou e continua sendo atendido. Às vezes por meses.

O ClubePro fecha os três. E o que você vende não é software: é previsibilidade de caixa, a coisa que o dono de comércio local mais quer comprar e menos consegue.

---

Como o dinheiro anda

Dois níveis de cobrança, com gateways separados que nunca se cruzam.

Você cobra o comércio. Você cria os planos (preço, limite de assinantes, limite de planos de clube) e cobra cada comércio no seu gateway. É a sua receita recorrente, e ela aparece na primeira linha do seu painel.

O comércio cobra o assinante. Ele configura o gateway dele numa tela do produto, e o dinheiro do assinante cai direto na conta dele, não passa por você, não passa pela Deplo, não passa por conta intermediária nenhuma.

As duas credenciais vivem em tabelas diferentes, cifradas em AES-256-GCM, lidas por funções diferentes. Não existe no código uma função que receba "o nível" como parâmetro: é assim que se garante que uma rota não consiga, por descuido, cobrar o assinante de um comércio com a sua chave. Um teste prova qual chave foi usada em cada cobrança, conferindo o cabeçalho Authorization que chega ao gateway.

---

O que cada um enxerga

Você (o dono da instalação) vê um painel de negócio: receita recorrente, comércios ativos, quem está em atraso, quantos assinantes existem na instalação inteira, quantos resgates em 30 dias. E a lista de comércios, cada um com o endereço da vitrine dele.

O lojista vê uma ferramenta de trabalho, na cor da marca dele: assinantes ativos, receita do mês, resgates de hoje, churn. E, no segundo item do menu, de propósito , o balcão.

O assinante vê uma vitrine pessoal no celular: o plano dele, quanto ainda tem de cada benefício no ciclo, quando é a próxima cobrança, o histórico do que já usou, e o código curto para ditar no balcão.

---

A tela de balcão

É a tela que define o produto, e foi desenhada primeiro em 390px, não adaptada depois.

Pense em quem usa: está de pé, atrás de um balcão, com um cliente na frente esperando, provavelmente com o celular na mão e uma mão só livre. Isso muda tudo.

• Busca de 56px de altura, com foco automático, por nome, telefone ou código.
• Resultados com alvo de toque de 72px. Se só houver um, a tela abre direto nele, é o que faz o fluxo caber em dois toques.
• O nome em corpo grande (28–32px) e a cota em número grande (44px), para ler de relance, de longe.
• Botão de resgate de 60px, que ocupa espaço de verdade.

E as recusas, que acontecem na frente do cliente e precisam ser claras sem constranger ninguém:

Situação	O que a tela diz
Cota esgotada	quanto o plano dá, quanto já foi usado, e em que data a cota volta
Pagamento pendente	pede para regularizar, e oferece avisar por WhatsApp
Pagamento não confirmado	"libera sozinho quando o pagamento cair"
Benefício fora do plano	diz que não faz parte daquele plano

---

A cota, e por que ela não acumula

A cota vale por ciclo e volta ao total na renovação. Isso não é limitação: é o que permite ao lojista manter o preço do plano abaixo do preço avulso. O produto deixa isso explícito nos termos de uso que ele publica.

O detalhe técnico que importa para você: a cota não é um saldo guardado. Não existe coluna "saldo" em lugar nenhum do banco. O usado é count(resgates) no ciclo corrente, e o ciclo corrente é derivado da data da primeira cobrança confirmada, avançando de mês em mês até conter o agora.

Duas consequências práticas:

• Não há job noturno. A virada do ciclo acontece pela passagem do tempo. Não existe rotina para falhar às três da manhã e deixar cinquenta clubes com a cota errada no dia seguinte.
• Não há divergência possível. Um saldo materializado pode discordar do histórico. Uma contagem, não.

E quando dois atendentes registram o mesmo resgate ao mesmo tempo, na última unidade da cota? A conferência e a gravação acontecem na mesma transação serializável: um passa, o outro recebe uma recusa clara. Isso é testado com transações concorrentes de verdade contra um Postgres de verdade, e o teste foi verificado ao contrário, quebrando o isolamento de propósito para confirmar que a cota realmente fura sem ele.

---

As regras que protegem o seu cliente

Só o webhook libera acesso. Nenhum clique de tela ativa uma assinatura. Nem o lojista consegue: não existe essa rota no produto.

Quem cancela continua sendo atendido até o fim do período já pago. Cancelar encerra as cobranças seguintes, não o mês que a pessoa já pagou.

Se o comércio atrasar com você, a vitrine sai do ar mas o balcão continua atendendo. Ninguém novo assina, essa é a pressão, mas quem já pagou não é punido pelo problema do lojista. É a regra mais contraintuitiva do produto, e a mais importante: cortar o atendimento faria o lojista perder justamente o cliente que você quer que ele mantenha.

Os dados de um comércio nunca aparecem para outro. O isolamento é testado recurso por recurso, plano, benefício, assinante, assinatura, resgate, vitrine, páginas, credencial de gateway, inclusive nas rotas endereçadas por id solto, que é onde esse tipo de coisa costuma vazar.

Os limites do plano são aplicados de verdade. Não são número de tabela: eles bloqueiam o cadastro de assinante e a publicação de plano, no painel e no autoatendimento, com uma mensagem que diz qual é o limite e quanto já foi usado.

---

LGPD

O produto tem front público e coleta dado pessoal de gente que ainda não é cliente de ninguém. Quem responde por esses dados perante a LGPD é o comércio, não você, e não a Deplo.

Cada comércio recebe três páginas escritas, contato, privacidade e termos, que nascem como rascunho, não publicadas. Publicar automaticamente um texto que ninguém leu dá aparência de conformidade sem revisão, o que é pior do que não ter página nenhuma. O texto de partida já nomeia o comércio como controlador, cita a Lei 13.709/2018, e diz que o fornecedor do software e a hospedagem são operadores.

Os dados do cartão não passam pelo sistema: o pagamento é processado pelo gateway que o próprio lojista contratou.

---

A instalação é sua

O ClubePro roda inteiramente na sua VPS. Ele não chama a Deplo, não envia telemetria e não valida licença. As únicas chamadas de rede que saem da instalação vão para o gateway de pagamento que você e os seus clientes configuraram, e isso é verificado por um teste que varre o código do backend atrás de qualquer outra saída.

Três containers: a interface (nginx servindo a SPA), a API e o Postgres. Os dois últimos não publicam porta nenhuma; nada além da interface é alcançável de fora.

O banco declara volume nomeado no manifesto, então o dado do seu cliente sobrevive ao redeploy, isso foi verificado removendo o container do banco e lendo os dados de volta.

---

O que está provado, e o que não está

131 testes automatizados contra Postgres de verdade, e dez controles negativos: para cada arquivo da suíte, um defeito real foi injetado no código de produção para confirmar que a suíte fica vermelha. Todos foram detectados.

Também estão medidos: os quatro cabeçalhos de segurança, o CORS restrito (conferido com origem inventada e com a real), o artefato dentro da imagem Docker, a ausência de rolagem lateral em 390px nas nove telas do painel, e a sobrevivência do dado à recriação do container.

O que não está provado está escrito com a mesma clareza no RELATORIO.md, inclusive que o fluxo de pagamento foi exercitado contra um gateway falso local, e que vale fazer uma cobrança de teste real antes da primeira venda.