"Autópsia: o app funcionava só na conta do dono"
"Na sua conta, tudo funciona. Na do cliente, erro. As três causas mais comuns, o teste de 15 minutos que acha a sua e o pedido certo pra IA."
"Sistema que só funcionavam usando uma conta específica. Qualquer outra conta retornava erro."
Quem escreveu foi um programador brasileiro, num fórum de tecnologia, contando o que encontrou num sistema feito no vibe coding (o jeito de construir pedindo pra IA, sem escrever código) que ele foi contratado pra arrumar. Já usei essa frase aqui pra falar de vazamento, quando o cliente B vê o dado do cliente A. Hoje é o avesso: o cliente B não vê nada. Só erro.
A cara do defeito é sempre a mesma. Você mostra o app pro sócio no seu celular e tudo funciona. Ele cria a conta dele e a primeira tela já quebra. Você volta pro seu, funciona de novo.
Por que não é culpa sua
Você construiu o app com uma conta: a sua. Cada pedido pra IA foi testado nela. Depois de semanas, essa conta acumulou coisas que nenhuma outra tem: uma linha criada na mão durante um conserto, uma permissão que a IA te deu pra destravar uma tela, um cadastro de loja feito uma vez só.
O app não ficou "funcionando". Ficou funcionando pra quem tem tudo que a sua conta tem. E a IA confere igual a você: na conta que está logada.
As três causas que eu mais vejo
O relato do fórum não diz qual era a causa naquele sistema. As três abaixo não vêm dele: são as que aparecem quando eu abro um app com esse sintoma.
1. A linha que só você tem
Quase todo app guarda, além do login, uma ficha do usuário: nome, plano, a loja dele. No Supabase (o banco que fica por trás do Lovable e de muita outra ferramenta), essa ficha costuma morar numa tabela chamada profiles. A própria documentação explica que a ficha precisa nascer sozinha a cada cadastro, por um gatilho: "para atualizar sua tabela profiles toda vez que um usuário se cadastra, configure um gatilho". E avisa: "se o gatilho falhar, ele pode bloquear os cadastros, então teste bem".
O que acontece no app gerado: a sua ficha foi criada na mão, num dia de conserto, antes do gatilho existir. Ou o gatilho nunca existiu. Você tem ficha; quem chega depois, não. Toda tela que pergunta "qual é o plano desse usuário?" recebe vazio e quebra.
2. Você é o administrador escrito no código
Pra destravar a tela de admin, a IA às vezes resolve do jeito mais curto: "se o e-mail for fulana@gmail.com, mostra tudo". E fica lá. Partes do app passam a supor que quem está logado é você, e quem não é cai num caminho que ninguém testou.
3. O cadastro que foi feito uma vez só
O app pede que todo usuário pertença a uma empresa, uma loja, uma clínica. A sua foi criada no primeiro dia, na mão, e ligada à sua conta. A conta nova não tem empresa nenhuma, e nenhuma tela foi feita pra criar uma. O cliente entra e trava num lugar onde você nunca passou.
O teste de 15 minutos
1. Conta nova, e-mail que nunca entrou no app (3 minutos). Cadastre-se como um cliente faria e passe por todas as telas, anotando cada uma que dá erro. (Tela só vazia, sem erro, é outro defeito.)
2. Compare as duas fichas (5 minutos). No painel do Supabase, abra o Table Editor (o editor de tabelas, que mostra o banco como planilha). Procure a tabela de usuários: profiles, usuarios, users. Ache a sua linha e a da conta nova.
- A conta nova não tem linha nenhuma? Causa 1.
- Tem linha, mas a sua tem colunas preenchidas que a dela não tem (
role,empresa_id,plano)? Causa 3, ou a 1 pela metade.
Só olhe. Não edite nada aí dentro.
3. Procure você no código (5 minutos). Cole isto pra IA, no modo que conversa sem mexer no código (no Lovable, o Plan mode):
"Liste todos os lugares do código que mencionam o e-mail
[seu e-mail]ou o ID do meu usuário. Para cada um, diga em uma frase o que acontece ali. Não altere nada."
Se aparecer qualquer coisa além de arquivo de teste, é a causa 2.
4. Anote o resultado (2 minutos). Uma linha por causa encontrada, com o nome da tela que quebrou.
O conserto, um pedido de cada vez
| Achou | O pedido |
|---|---|
| Causa 1 | "Todo cadastro novo deve criar a linha do usuário em profiles automaticamente. Crie também as linhas que faltam pros usuários que já existem sem ela. Me diga quantos eram antes de criar." |
| Causa 2 | "Remova toda verificação por e-mail fixo no código. Quem é administrador fica marcado numa tabela no banco, e a regra de acesso confere essa tabela no servidor, não na tela." |
| Causa 3 | "Quando um usuário entra sem empresa ligada, mostre uma tela pra ele criar a dele. Nenhuma tela pode supor que a empresa existe." |
Depois de cada um, o teste é outra conta nova, não a que você criou no passo 1. Aquela já pode ter sido remendada no meio do caminho e virar uma segunda "conta do dono". Uma conta que nunca existiu é a única que conta a verdade.
E guarde o hábito: a IA mexeu em cadastro, login ou permissão, você cria uma conta do zero antes de dizer que está pronto.
Era uma parede de várias
Esse defeito mora na fase que eu chamo de Estruture: de quem é cada dado e quem pode o quê. A conta nova pega o erro. Não pega se a regra de quem é admin está certa, nem se um cliente vê o dado do outro, nem se o gatilho que você acabou de criar vai bloquear o cadastro num dia de pressa. Cada um tem o seu teste, e eles têm ordem.
O programador do relato terminou com uma frase: "agora estou refatorando tudo". Dá pra chegar antes dele, quando ainda é uma conta nova e quinze minutos.
Fontes
- Relato "Sistema que só funcionavam usando uma conta específica", TabNews (registrado na pesquisa do blog,
pesquisa/03-swipe-file-verbatim.md; relato de um programador, não estatística) - Supabase Docs, "User Management" (tabela própria no schema
public; gatilho pra criar a linha a cada cadastro; "if the trigger fails, it could block signups"): https://supabase.com/docs/guides/auth/managing-user-data