Veja o Plano de Tratamento com
dados de um app fictício.
Esse é um exemplo real do formato e do nível de detalhe do plano que a gente entrega quando você paga os R$ 97 e a gente analisa o seu app. O conteúdo abaixo foi feito para um app fictício chamado AppTeste. O seu plano sai específico pro seu app, com seus números, sua plataforma e seus prompts.
- Exame Express diz onde tem problema.
- Plano de Tratamento diz exatamente o que fazer primeiro, em que ordem, com prompts colável no builder e revalidação inclusa.
Para Caroline · appteste.lovable.app · 12 de maio de 2026
App funciona bem na demo e tem 14 clientes pagos, mas três coisas (custo da OpenAI sem teto, ausência de política de privacidade e layout estourando no celular) vão queimar dinheiro de Meta Ads se você ligar a campanha sem corrigir.
1. Pôr um teto de custo na OpenAI antes do tráfego
Impacto: Alto · Esforço: Baixo · Tempo: ~10min
Por que importa pra este caso: O scan detectou 8 chamadas pra api.openai.com/v1/chat/completions por sessão, todas client-side. Sem rate-limit, um único usuário curioso fazendo 200 perguntas custa R$ 18. Com 1.000 visitantes vindo de ads e taxa de conversão típica de 2%, você gasta R$ 1.800 pra fazer 20 vendas. Margem zerada.
O que fazer: Move a chamada da OpenAI pro backend (API route do Lovable), adiciona um contador de chamadas por usuário/dia em variável Supabase, e bloqueia depois de 20 chamadas com mensagem "limite diário atingido, volte amanhã ou faça upgrade". Para usuários pagos, sobe pra 200.
Prompt pra colar no Lovable:
Mova todas as chamadas à API da OpenAI que estão no frontend pra uma API route segura no servidor. Adicione uma tabela "openai_usage" no Supabase com colunas user_id, date, calls_count. Antes de cada chamada, incremente o contador e bloqueie se ultrapassar 20 chamadas no dia para usuários free, 200 para usuários paid. Quando bloquear, devolva mensagem amigável ao usuário em vez de erro técnico. Não altere o fluxo visível da UI; só adicione a verificação no backend.
2. Política de Privacidade + canal de contato (não dá pra rodar Meta Ads sem)
Impacto: Alto · Esforço: Médio · Tempo: ~45min
Por que importa pra este caso: O Meta exige link funcional de política de privacidade ativo no domínio do anunciante; sem ela, o anúncio é reprovado ou pausado em 48h. E o app coleta CPF, contas bancárias e renda (dados sensíveis pela LGPD). Multa máxima da ANPD pra empresa sem política é 2% do faturamento, até R$ 50 milhões.
O que fazer: Cria duas páginas: /privacidade explicando quais dados coleta (CPF, renda, transações), com que base legal (consentimento e legítimo interesse), prazo de retenção, e como pedir exclusão. E /contato com pelo menos email de suporte mais um link de WhatsApp. Linka as duas no rodapé de todas as páginas.
Prompt pra colar no Lovable:
Crie a página /privacidade contendo a política em PT-BR explicando: quais dados pessoais o app coleta (CPF, renda, transações bancárias, email), com que base legal (consentimento + legítimo interesse para operação do serviço), por quanto tempo mantemos (5 anos após o cancelamento ou conforme exigir a Receita Federal), quais terceiros têm acesso (Supabase como processador, OpenAI para sugestões anônimas), e como o titular pode exercer direitos LGPD (acesso, correção, exclusão) via email [email protected]. Crie também a página /contato com email de suporte e link de WhatsApp. Adicione as duas no rodapé global do app.
3. Estouro de layout no celular
Impacto: Médio · Esforço: Baixo · Tempo: ~20min
Por que importa pra este caso: A renderização mobile mostrou Cumulative Layout Shift de 0.31 (limite seguro é 0.1) e, em viewport de 375px (a largura da maioria dos celulares em uso hoje), o card de "saldo do mês" aparece cortado no screenshot do Playwright, forçando scroll horizontal. Você está rodando Meta Ads e quase todo o tráfego vem de celular. Cliente que abre, vê layout quebrado, sai antes de cadastrar.
O que fazer: O card de saldo está com largura fixa em px no CSS. Troca pra container responsivo (max-width em porcentagem ou clamp()) e testa de 360px pra cima pra o resumo principal não estourar a viewport.
Prompt pra colar no Lovable:
O componente "MonthlyBalanceCard" está estourando a largura em celular (testei em 375px e o conteúdo passa da viewport). Verifique o CSS dele: substitua qualquer width fixo em pixels por max-width com porcentagem ou clamp(). Adicione um media query para telas até 400px que empilha verticalmente o "saldo" e os "gastos por categoria" em vez de colocar lado a lado. Teste em emulação de celular (375px) no Lighthouse e garante que o CLS fica abaixo de 0.1 e que não há scroll horizontal.
4. Fechar as brechas de segurança que o scan apontou
Impacto: Alto · Esforço: Baixo · Tempo: ~25min
Por que importa pra este caso: Pra um app que coleta CPF e dados bancários, o scan achou três sinais que, somados, abrem a porta. (1) Faltam os headers HSTS, CSP, X-Frame-Options e X-Content-Type-Options; sem CSP, um <script> injetado via input mal sanitizado lê o localStorage onde está o JWT do usuário. (2) A tela de login carrega um banner por http:// puro dentro de uma página https:// (conteúdo misto), e o navegador mostra o cadeado quebrado bem na hora de digitar a senha. (3) Onde o HSTS aparece, vem com max-age de 1 dia, perto de não existir.
O que fazer: Configura os quatro headers no painel do Lovable (campo "Custom Headers"), com HSTS de 1 ano, e troca o asset http:// por https:// (ou hospeda no próprio domínio) pra eliminar o conteúdo misto.
Prompt pra colar no Lovable:
Configure estes Custom Headers no projeto pra todas as rotas:
- Strict-Transport-Security: max-age=31536000; includeSubDomains
- X-Frame-Options: DENY
- X-Content-Type-Options: nosniff
- Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' https://js.stripe.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self' https://api.openai.com https://*.supabase.co
Depois, encontre qualquer recurso (imagem, script, iframe) carregado por http:// e troque por https://, pra eliminar o aviso de conteúdo misto.
Aplique sem quebrar a integração de pagamento do Stripe nem as chamadas pra Supabase e OpenAI.
5. Recuperação de senha não envia email
Impacto: Médio · Esforço: Baixo · Tempo: ~20min
Por que importa pra este caso: Testamos o fluxo "Esqueci minha senha" e o email nunca chegou. Provavelmente o Supabase está usando o sender de development que tem cap em 3 emails/hora. Quando você ligar tráfego, cliente esquece senha, não recebe, abandona, vira chargeback.
O que fazer: Configura SMTP custom no Supabase Auth (Resend ou SendGrid free tier dão conta de até 100 emails/dia). Customiza o template do email pra ter sua marca em vez do template Supabase genérico.
Prompt pra colar no Lovable:
Configure SMTP customizado no Supabase Auth do projeto. Use Resend com tier gratuito (resend.com, até 3000 emails/mês). Customize os templates de "magic link" e "reset password" pra terem o nome "AppTeste" no remetente, o logo no header e tom amigável em PT-BR em vez do template default do Supabase. Inclua um link de suporte no rodapé do email apontando pra /contato.
Matriz impacto × esforço
| Correção | Impacto | Esforço | Quando |
|---|---|---|---|
| 1. Teto de custo OpenAI | Alto | Baixo | Hoje |
| 2. Política LGPD + Contato | Alto | Médio | Hoje |
| 3. Estouro de layout no celular | Médio | Baixo | Esta semana |
| 4. Brechas de segurança (headers, HSTS, conteúdo misto) | Alto | Baixo | Esta semana |
| 5. Email de reset | Médio | Baixo | Antes do tráfego |
Ordem de execução
Hoje (90 min): correções 1 e 2. Sem teto de OpenAI e sem política de privacidade, qualquer real gasto em ads é desperdício certo.
Esta semana (35 min): correções 3 e 4. Antes de subir o orçamento de ads.
Antes de qualquer pico de tráfego: correção 5. Faz um teste de "esqueci senha" com email real e confirma que chegou em menos de 30 segundos.
Como funciona a revalidação
Quando aplicar tudo, responde este plano com a frase "pronto pra revalidar". A gente roda um novo scan focado nas cinco correções, atualiza o boletim, e confirma que o app está pronto pra receber tráfego. Inclui no preço do plano, sem cobrança adicional.
Quer ir ainda mais fundo?
Este plano leu o AppTeste pela URL pública, a mesma coisa que um cliente (ou um concorrente) enxerga de fora. O miolo do app (o que roda atrás do login, no Supabase e nas funções serverless) não aparece num scan de fora.
Se você compartilhar o repositório do Lovable e um acesso de teste, a próxima versão deste plano entra por dentro e cobre:
Segurança dos dados
- Se as tabelas do Supabase têm Row Level Security configurada, ou se um usuário consegue ler os gastos de outro só trocando um id na URL (o vazamento mais comum em app no-code).
- Onde o token de sessão fica guardado (localStorage, vulnerável a XSS, ou cookie HttpOnly), e se alguma chave secreta (OpenAI, service_role do Supabase) está embutida no bundle do frontend.
Custo e escala
- Mapa de custo por endpoint: quanto cada feature gasta hoje em chamadas pagas, pra você saber o teto real antes de subir o orçamento de ads.
- Se as funções serverless têm tratamento de erro e timeout, ou se uma falha da OpenAI derruba a tela inteira.
Dinheiro entrando
- Se o webhook do Stripe é idempotente (não credita duas vezes) e valida assinatura, o tipo de bug que vira chargeback ou crédito indevido.
Tudo isso já está no preço do Plano de Tratamento, sem cobrança adicional. É só mandar o link do repo no campo de aprofundamento e a próxima versão do plano volta com essas análises internas.
Quando você compartilha o código,
o plano entra por dentro.
O Exame Express e este plano leem o app pela URL pública, o mesmo que um cliente vê de fora. Se você compartilhar o repositório e um acesso de teste (sem custo extra, já está no preço do plano), a próxima versão cobre o que um scan de fora nunca enxerga:
- RLS do Supabase: um usuário consegue ler os dados de outro trocando um id na URL?
- Onde o token de sessão fica (localStorage vulnerável a XSS vs cookie seguro)
- Chaves secretas (OpenAI, service_role) vazando no bundle do frontend
- Mapa de custo por endpoint antes de subir o orçamento de ads
- Funções serverless com tratamento de erro e timeout
- Webhook de pagamento idempotente e com validação de assinatura
- Fluxo de cobrança sem crédito duplicado ou chargeback fácil