A lei dentro do nosso código
Um botão de cancelamento que precisa funcionar sem login. Um formulário que nunca pode rejeitar você. Por que deveres legais são arquitetura para nós, e não texto padrão.

Quando tornamos o Premium comprável, achamos que a parte jurídica seria algumas páginas de texto no rodapé. Estávamos errados. Alguns deveres não podem ser escritos num texto, porque determinam como um recurso precisa ser construído.
Quatro exemplos em que isso ficou especialmente claro. Antes de tudo, para deixar claro do que se trata: esta é uma descrição da nossa implementação, não assessoria jurídica. As regras abaixo são do direito alemão, que é onde o AlphaCloud opera.
O botão de cancelamento que não pode ter login
O § 312k do Código Civil alemão exige que contratos fechados online ofereçam um caminho diretamente acessível para cancelar. Isso gera requisitos que você não consegue acrescentar depois só mudando a redação:
- A página precisa funcionar sem login
- Ela precisa estar no rodapé de todas as páginas
- Ela precisa de duas etapas: preencher e depois confirmar por um botão com rótulo inequívoco
- Uma confirmação de recebimento em forma de texto precisa ser enviada
O último ponto define a arquitetura. Um cancelamento é uma declaração unilateral e produz efeito ao ser recebido. Portanto, ele precisa ser registrado e confirmado sempre, venha de quem vier.
O formulário nunca pode rejeitar você
Foi aqui que a abordagem óbvia quase nos levou a um erro.
A abordagem óbvia: só aceitar o cancelamento se o ID do servidor e o e-mail baterem com uma assinatura ativa. Parece razoável e está errado duas vezes.
Primeiro, isso bloquearia um cliente real que digita o e-mail errado ou informa outro endereço. O cancelamento dele não teria sido recebido, a assinatura renova, e ele tem provas de que tentou.
Segundo, e esta é a parte mais desagradável: a própria mensagem de erro seria uma resposta. Quem recebe de volta "nenhuma assinatura encontrada" descobre que aquele servidor não paga. O ID de um servidor do Discord não é segredo, qualquer membro consegue lê-lo. O formulário viraria uma ferramenta para sondar os servidores dos outros.
A solução separa duas coisas que parecem uma só:
| Condição | |
|---|---|
| Recebimento da declaração | incondicional, sempre registrado e confirmado |
| Execução do cancelamento | só quando o e-mail enviado bate com o do comprador cadastrado |
Todo o resto vai para uma fila e é revisado por uma pessoa. Isso é permitido porque o § 312k, parágrafo 2, autoriza expressamente pedir dados de identificação. Proibido é só um login antes disso.
Pelo mesmo motivo, a resposta pública só pode citar a data de término depois que a identidade for confirmada. Caso contrário, a confirmação vira um oráculo de novo.
O arrependimento que tem login de propósito
Logo ao lado fica um recurso que construímos do jeito oposto: o arrependimento com reembolso proporcional fica atrás de um login.
Isso não é contradição. O § 312k trata do cancelamento, não do arrependimento, e não há nenhuma obrigação de oferecer um formulário online de arrependimento, desde que o caminho informal continue aberto. A diferença está na consequência: um cancelamento age sobre o futuro, um reembolso move dinheiro agora, e não dá para desfazê-lo.
Três regras que decorrem disso e que não afrouxamos:
Sem motivo obrigatório. O § 355, parágrafo 1, garante o arrependimento expressamente sem necessidade de justificativa. O campo é opcional e tem que continuar opcional, por mais tentador que um campo obrigatório fosse para as estatísticas.
Depois de 14 dias, só o caminho automático é recusado, nunca a declaração. O prazo se estende para até doze meses e quatorze dias se o cliente não tiver sido devidamente informado. Um "tarde demais" genérico poderia, portanto, estar errado.
A proteção contra pagar duas vezes é pessimista. A marcação é feita antes de o reembolso rodar. Se o reembolso falhar, a marcação fica e uma pessoa assume. Pagar duas vezes é o único desfecho que não tem conserto.
Uma DM do Discord não é um suporte durável
O § 312f, parágrafo 3, exige uma confirmação do contrato em suporte durável, e ela precisa reproduzir o consentimento que foi dado.
Primeiro mandamos uma mensagem direta no Discord, porque é o canal onde nossos clientes já estão. Isso não basta. Uma DM vive numa plataforma que não controlamos e não é armazenável nem inalterável no sentido que a norma exige.
Por isso entrou um e-mail, e com ele uma dependência desconfortável: se as credenciais de e-mail não estiverem configuradas, o envio só escreve um aviso no log e o dever não é cumprido. Um dever legal pendurado numa variável de ambiente é um estado do qual vale a pena ter consciência.
Sem IVA, e isso tem que estar escrito igual em todo lugar
O AlphaCloud é uma pequena empresa nos termos do § 19 da lei alemã do imposto sobre valor agregado. Os preços são preços finais, e o IVA nunca é exibido.
Parece uma nota de rodapé e, na verdade, é uma tarefa de consistência em muitos lugares: a página de preços, a janela de checkout, os termos, a política de privacidade, o rodapé da fatura e a configuração no provedor de pagamento precisam dizer a mesma coisa. Por muito tempo tivemos ali um "mais IVA" que estava simplesmente errado.
E a IA
Desde agosto de 2026, as obrigações de transparência do Regulamento Europeu de IA se aplicam por completo. Qualquer pessoa conversando com um sistema de IA precisa conseguir perceber isso, no máximo na primeira interação.
A frase mais importante dessa revisão para nós: uma página jurídica no rodapé provavelmente não basta. O aviso precisa acontecer onde a interação acontece, ou seja, na própria mensagem do Discord. Por isso o nosso suporte de tickets com IA se apresenta sozinho e tem um botão visível para desligá-lo. Nossa avaliação detalhada está em transparência de IA.
O fio condutor
Os quatro exemplos têm a mesma forma: o dever parecia um texto e, na verdade, era um requisito sobre a estrutura. Um login no lugar errado, uma mensagem de erro que revela demais, uma confirmação no canal errado, uma ordem de execução que permite pagar duas vezes.
Por isso, hoje lemos texto jurídico como uma especificação, e também verificamos na direção contrária: o código faz mesmo o que os nossos termos dizem? Exatamente nessa pergunta encontramos duas divergências reais, e há um artigo separado sobre elas.
Mais artigos
Por que quase tudo no AlphaCloud continua grátis
A maioria dos bots do Discord tranca seus recursos mais úteis atrás de uma assinatura. Nós deliberadamente não fazemos isso, e isso tem menos a ver com generosidade do que parece.
BastidoresDe olho em 4.000 servidores do Discord: Grafana, PostHog e o que eles nos mostraram
Um loop que causava em silêncio metade do nosso tráfego, três milhões de requisições inúteis por dia e um ataque que acabou depois de um minuto. O que o nosso monitoramento vê e o que ele deliberadamente não vê.
BastidoresO que uma auditoria do nosso próprio sistema de pagamento revelou
Duas descobertas críticas, e nenhuma estava onde teríamos procurado. Um relato aberto sobre erros que já foram corrigidos.