Confirmação de e-mail: quando um vibe coder não pede verificação

Se a persona não abre e-mail, confirmação de e-mail no cadastro é um muro. Jhonatan está construindo a Churchflix, plataforma white-label de cursos para igrejas, e recusou a verificação porque o público dele é pastor e gente de idade. Eles escrevem qualquer coisa no campo. O que precisam lembrar depois é a senha.

Ele disse que dá para criar conta com qualquer e-mail. O produto aceita o que a pessoa escrever. O problema começa se ele exige que essa pessoa saia dali, abra o inbox e clique num link.

se eu colocar validação, o meu público precisa ficar indo lá no e-mail e verificar, mas o meu público não faz isso. Eles não entendem essas coisas.

Ele encurta o processo até o ponto em que essa pessoa consegue terminar o cadastro sozinha. Isso aparece também em teste de usabilidade.

Quem escreve qualquer e-mail e só precisa da senha

Quem programa com IA recebe de volta o cadastro pronto: campo de e-mail, campo de senha, depois a confirmação de e-mail, e só então o primeiro uso. Esse fluxo assume um usuário que vive no Gmail. O pastor da Churchflix chega sem esse hábito. O mesmo problema apareceu em vibe coding para nao deixar o desfazer expirar em 6 segundos.

Jhonatan corta o passo. Quem entra com Google já entende um pouco e resolve por ali. Quem não entende preenche o formulário como conseguir. Foi o mesmo caminho de vibe coding para deixar o aluno pular a aula.

Agora o meu público que não entende que são pastores, gente de idade e etc, ele vai escrever qualquer coisa, mesmo que se ele escrever errado, ele só tem que lembrar a senha dele.

O e-mail digitado errado não trava a entrada. A conta existe. O próximo login depende da senha, não de um link que ninguém abriu. Se a pessoa se perder, o time de suporte atende e dá supervisão. O tutorial colocaria o controle no inbox. Jhonatan colocou numa conversa com o usuário. O mesmo problema apareceu em vibe coding para nao deixar ocr falhar em silencio.

No login seguinte, o que importa é a senha. O e-mail pode estar certo ou errado. Ele aceita o e-mail errado para o cadastro não morrer na caixa de entrada de quem não vai abri-la. Isso aparece também em vibe coding para nao consertar o codigo so para o teste passar. Vale ver como isso terminou em multi tenant o que é.

Google para quem já entende, suporte para o resto

O público meu que entrar com o Google, ele já entende um pouquinho, então ele pelo Google vai resolver.

São 2 jeitos de entrar no mesmo produto. Quem já usa Google Login atravessa o cadastro sem escrever e-mail à mão. Quem não usa escreve o que lembrar e segue. Jhonatan não empurra os 2 grupos para o mesmo caminho pelo inbox. Isso aparece também em notificacao push.

Quem chega pelo Google já passou por uma conta que ele sabe usar. Quem chega pelo formulário pode errar o e-mail e ainda assim entrar, desde que a senha fique na cabeça. Se isso gerar um problema depois, o suporte assume. Jhonatan prefere esse custo operacional ao custo de perder o cadastro no e-mail que ninguém abre. Isso aparece também em anonimização de dados.

Ele compara com uma plataforma boa que eles usam. É muito boa, ele diz. Tem tanta coisa no processo que o pastor e o senhor não entendem, inclusive como pular uma aula. A confirmação de e-mail seria mais um degrau desse tipo: certo no papel, parado na mão de quem não abre e-mail. O mesmo problema apareceu em ia local.

No vibe coding, o fluxo padrão perde para a persona

tem que entender qual que é a nossa persona

No vibe coding, o agente devolve o cadastro de SaaS padrão. Confirmação de e-mail chega no fluxo sem ninguém pedir. Se você não escrever a restrição da persona no pedido, o passo entra no produto sem ninguém ter perguntado se aquele público abre e-mail. O mesmo problema apareceu em vibe coding para nao deixar o agente zerar a conta. Vale ver como isso terminou em vibe coding para preservar texto original. O mesmo problema apareceu em fazer email corporativo.

Jhonatan falou a restrição em voz alta. O público não faz isso. Eles não entendem essas coisas. A confirmação de e-mail cobra um clique que esse usuário não vai dar. Quem usa o produto não é quem está gerando o código. O vibe coding só entrega um fluxo que a persona consegue completar se essa restrição entrar no pedido. Isso aparece também em vibe coding para nao deixar contexto antigo escolher o modelo. Vale ver como isso terminou em vibe coding para nao deixar o grafico vazio de quem esta indo bem.

O pedido concreto, no caso dele, cabe em poucas linhas: não pedir confirmação de e-mail, aceitar o que o pastor escrever, deixar o Google Login para quem já entende e mandar o resto para o suporte. Sem essa frase, a IA recoloca a verificação porque é o que o tutorial de cadastro ensina. Vale ver como isso terminou em vibe coding para nao confiar em teste que o agente escreveu.

Descreva a persona antes de gerar o cadastro

Antes de pedir o cadastro para a IA, escreva quem vai criar a conta. No caso da Churchflix, a resposta é pastor e gente de idade, gente que não vai no e-mail verificar nada. Com essa frase no pedido, o Google Login fica para quem já entende e o campo aberto fica para quem vai escrever qualquer coisa. O suporte entra quando o e-mail estiver errado.

Dá para assistir à live e ouvir o momento em que ele recusa a validação. Se o seu produto também serve quem não vive no inbox, o primeiro corte no cadastro gerado pela IA é esse e-mail de verificação.