MÓDULO 5.3

🚀 Projeto: App Full-Stack (Lead Qualifier) + Frontend pra n8n

O projeto mais ambicioso: um app que outras pessoas usam. Backend que qualifica leads (Trigger.dev) + frontend (Vercel), conectados por env vars. Depois você adiciona autenticação (Supabase + RLS), faz uma auditoria de segurança, cobra com Stripe (freemium) e ainda constrói um frontend para um workflow n8n (form → webhook). Tudo em iteração incremental: design → auth → pagamento.

8
Tópicos
~90
Minutos
Avançado
Nível
Projeto
Tipo
Progresso do módulo 0% · 0 de 8

🧰 Pré-requisitos e como usar

Este é um build full-stack. Cada caixa abaixo é um prompt para copiar e rodar, com 🎯 objetivo e ✅ como verificar; troque o que está entre <chaves>. Pré-requisitos: contas no Trigger.dev, Vercel, Supabase e Stripe; GitHub conectado; uma chave de IA (ex.: Anthropic). A regra de ouro do módulo é iterar em camadas: app funcional → design → auth → segurança → pagamento, testando a cada passo.

O salto deste módulo é o front + back. O que o usuário vê (o frontend, na Vercel) é uma casca bonita; o trabalho de verdade acontece no backend (a lógica do agente, no Trigger.dev). Eles conversam — e tudo o que os liga (URL, chaves) viaja por env vars, nunca escrito no código.

🙋 usuáriopreenche o form 🖥️ Frontend · Vercel o que o usuário vê form + resultado ⚙️ Backend · Trigger.dev IA qualifica o lead score · resumo · próximos passos 📈 score68/100 · warm env var liga as pontas 🔐 Supabase — login + RLS (dados) 💳 Stripe — assinatura (freemium)

Diagrama ilustrativo — frontend (Vercel) e backend (Trigger.dev, em ciano como "máquina") ligados por env vars; Supabase e Stripe entram como camadas depois.

1

🏛️ A arquitetura: backend + frontend

O que é

O app tem duas pontas. O frontend é tudo o que o usuário vê (o formulário e a tela de resultado), hospedado na Vercel. O backend é o workflow de IA que qualifica o lead (a lógica de negócio), hospedado no Trigger.dev. Eles se comunicam para que qualquer pessoa com a URL possa usar o fluxo. O resultado é uma tela com um score (ex.: 68/100, "lead morno"), um resumo, o detalhamento do score e os próximos passos sugeridos.

O que é?Frontend — o que roda no navegador, a interface. Backend — o que roda no servidor (lógica, chamadas de IA, banco). Ciclo request/response — você clica, o frontend manda um pedido, o backend processa e devolve a resposta, a tela atualiza.

🎯 Objetivo: planejar o app inteiro e gerar o CLAUDE.md (em Plan Mode).

prompt (copie e rode em Plan Mode)
Me ajude a rascunhar o CLAUDE.md. Quero construir um workflow no framework WAT.
Crie uma pasta para cada seção, exceto o agente.

O workflow é um qualificador de leads com IA: eu envio dados de um lead e a IA
o qualifica. Stack: vou hospedar o workflow no Trigger.dev. Vou criar um frontend
com sua ajuda onde eu preencho um formulário sobre o lead, clico em "Analisar",
e o workflow no Trigger.dev é chamado. Quando ele terminar, mostra os resultados
no frontend. Por fim, eu publico o frontend na Vercel via GitHub.

Meu backend fica no Trigger.dev e meu frontend na Vercel, e eles precisam
conseguir se comunicar.

✅ Como verificar: a IA cria o CLAUDE.md e a estrutura base (pastas de workflows/tools) seguindo o WAT, antes de codar. Revise o plano antes de aprovar.

Por que aprender

Entender a divisão front/back é o que destrava construir produtos, não só automações. O frontend torna o agente acessível; o backend mantém a lógica e os segredos longe do navegador. Começar pelo CLAUDE.md dá à IA o contexto persistente do projeto inteiro.

Conceitos-chave

Frontend

Vercel · o que se vê.

Backend

Trigger.dev · a lógica.

Request/response

Pedido → resposta.

CLAUDE.md

Contexto do projeto.

2

⚙️ Build do lead qualifier (do prompt ao app)

O que é

Com o plano pronto, você constrói o backend e depois o frontend. O backend recebe os dados do lead (empresa, setor, porte, critério, urgência, dores), pontua com IA e devolve a classificação. Você cria o projeto no Trigger.dev, cola o Project ID no trigger.config.ts e faz o deploy nos ambientes de dev e prod. A chave de IA entra como env var no painel.

🎯 Objetivo: construir o workflow e colocá-lo em dev e prod.

prompts (na sequência)
[1] Crie o workflow do qualificador e me guie no deploy para o Trigger.dev.

[2] Estou vendo estes passos no Trigger.dev, me ajude a configurar —
    já atualizei o trigger.config.ts com o meu project ref <project-id>.

[3] A tarefa foi adicionada ao ambiente de DEV no Trigger.dev, mas não vejo
    no ambiente de PRODUÇÃO. Configure isso pra mim.

✅ Como verificar: a tarefa aparece em dev E prod (erro comum: ela nasce só em dev). Adicione a chave de IA (ex.: Anthropic) como env var nos dois ambientes — de preferência chaves separadas para acompanhar custo.

🎯 Objetivo: construir o frontend bonito (após /clear, em Plan Mode).

prompt (copie e rode)
Agora que meu backend está pronto (o workflow do qualificador), quero construir
o frontend. Deve ser um formulário onde eu preencho dados de uma empresa, e ao
clicar em "Analisar" ele chama meu workflow no Trigger.dev. Quando o workflow
terminar, quero ver os resultados no site. Primeiro quero ver o site LOCALMENTE
para avaliar o design. Aprovado o design, eu publico na Vercel.
Para o design, use a skill de front-end design da Anthropic.

✅ Como verificar: rode local primeiro e avalie o visual. A skill de design cuida de tipografia, cores e movimento — fugindo do "look genérico de IA" (o gradiente roxo de sempre).

Por que aprender

Este tópico repete o padrão "descreva o resultado completo", agora num contexto full-stack — e mostra dois gotchas reais: promover a tarefa de dev para prod (não acontece sozinho) e chamar a skill de design para o frontend não sair com a aparência padrão. Teste o app local antes de publicar.

Conceitos-chave

Project ID

No trigger.config.ts.

Dev + prod

Promova pra produção.

Skill de design

Foge do look genérico.

Local 1º

Avalie antes de publicar.

3

🔌 Conectar frontend ↔ backend (env vars)

O que é

A costura entre as pontas é uma env var: o frontend na Vercel descobre o backend (e a chave de acesso) por uma variável de ambiente, nunca por um valor escrito no código. Você publica na Vercel (conectando o GitHub) e adiciona o secret key do Trigger.dev como env var na Vercel — em produção e desenvolvimento — sem nunca colar a chave no chat.

O que é?Variável de ambiente (env var) — um valor (URL, chave) configurado fora do código e injetado em tempo de execução. Trocar de ambiente (dev/prod) é trocar o valor, não o código.

🎯 Objetivo: publicar na Vercel e ligar o frontend ao backend com segurança.

prompt + passo manual
[prompt] O site ficou ótimo. Agora quero publicá-lo na Vercel. E garanta que
ele consiga se comunicar com o meu workflow no Trigger.dev quando eu clicar
em "Analisar". Não quero colar a chave secreta no chat — me diga onde colocá-la.

[passo manual]
Trigger.dev → API Keys → copie o secret key
Vercel → projeto → Settings → Environment Variables → nova var:
  Name:  TRIGGER_SECRET_KEY
  Value:       (production + development)
Depois: "Já configurei o secret key no painel da Vercel." → redeploy

✅ Como verificar: clique em "Analisar" e veja o score voltar. Se der erro de modelo (ex.: 404 — nome de modelo inexistente), a conexão até funcionou; basta: "Rodei o workflow e deu este erro: <erro>. Corrija e refaça o deploy."

Por que aprender

Env vars são o que fazem as duas pontas conversarem com segurança: a chave fica no painel, não no código que vai para o navegador. Note o hábito de não colar segredos no chat — você mesmo configura e só avisa a IA onde a chave está. Erros de conexão são normais; o ciclo é devolver o erro e refazer o deploy.

Conceitos-chave

Env var liga

URL + chave do backend.

Você configura

Chave nunca no chat.

Auto-deploy

Push → Vercel publica.

Erro → fix

Devolva e redeploy.

4

👤 Autenticação com Supabase + RLS

O que é

Um app aberto é um problema: qualquer um com a URL dispara o workflow e gasta seus tokens de IA (você paga pelo uso dos outros). A solução é autenticação com Supabase (login/cadastro, cada usuário com seu histórico) e, crucialmente, RLS (Row-Level Security): regras que vivem no próprio banco e impedem um usuário de ver dados de outro — mesmo que haja um bug no frontend.

O que é?RLS (Row-Level Security) — regras no banco que limitam quais linhas cada usuário enxerga. É uma camada extra: mesmo com um bug na interface, o banco recusa entregar dados alheios. Migration — um script SQL que altera a estrutura do banco (ex.: criar a tabela leads).

🎯 Objetivo: adicionar login/cadastro e proteger as rotas (em Plan Mode).

prompt (copie e rode em Plan Mode)
Quero adicionar autenticação ao qualificador de leads. Os usuários devem poder
se cadastrar, fazer login e ver o próprio histórico de qualificações. Quero usar
o Supabase, e proteger as rotas principais do app para que só usuários logados
acessem. Nunca usei Supabase — me guie passo a passo na configuração.

✅ Como verificar: a IA gera as páginas de auth, a barra de navegação e o schema. No Supabase, crie o projeto, defina uma senha forte de banco (diferente da senha de login), escolha a região e habilite RLS.

🎯 Objetivo: conectar o Supabase e rodar a migration.

passos manuais
1. Supabase → copie o project URL e a publishable key.
2. Vercel → Settings → Environment Variables → adicione as duas → redeploy.
3. Supabase → Authentication → URL Configuration → adicione a URL do app (Vercel)
   e a redirect URL.
4. Migration: cole o SQL gerado pela IA no SQL editor do Supabase → Run
   (cria a tabela `leads`).

✅ Como verificar: aparecem páginas de login/cadastro, a navbar com conta + sair, e uma página de histórico com os leads persistidos por usuário (antes se perdiam ao fechar o navegador).

Por que aprender

Login sozinho não basta: sem RLS, um bug no frontend poderia mostrar os dados de um usuário a outro. RLS move a defesa para o nível dos dados, onde ela é confiável. É a diferença entre "parece protegido" e "está protegido".

Conceitos-chave

App aberto = risco

Gastam seus tokens.

Supabase

Login + banco.

RLS

Defesa no banco.

Migration

SQL no editor.

5

🛡️ Auditoria de segurança

O que é

Com auth no lugar, peça à IA para agir como uma especialista em segurança e varrer o código: rotas protegidas exigem login? alguma chave de API exposta no frontend? segredos vêm de env vars? o RLS está realmente habilitado? Ela reporta o que não passa, e você pede a correção.

O que é?Auditoria de segurança — uma revisão sistemática em busca de brechas. Rate limiting — limitar quantas vezes um endpoint pode ser chamado num intervalo, para evitar abuso de custo.

🎯 Objetivo: auditar o código em busca de problemas de segurança (após /clear).

prompt (copie e rode)
Quero que você audite o código em busca de problemas de segurança. Verifique que:
- todas as rotas protegidas exigem autenticação;
- nenhuma chave de API está exposta no código do frontend;
- variáveis de ambiente são usadas para TODOS os segredos;
- o Row-Level Security (RLS) está habilitado corretamente.
Aja como uma especialista em segurança e reporte tudo que não passar.

✅ Como verificar: o relatório classifica os achados (ex.: 1 médio, 3 baixos, 1 informativo, nenhum crítico/alto). Um achado típico e acionável: adicionar rate limiting no endpoint de qualificação para evitar abuso de custo. Peça à IA para corrigir os apontamentos.

Por que aprender

Um app em produção tem superfície de ataque. A auditoria pega o que é fácil de esquecer: uma rota sem login, uma chave que vazou para o cliente, RLS desligado. Tratar a IA como especialista de segurança é um padrão poderoso — ela conhece as brechas comuns e te aponta o que você não veria.

Conceitos-chave

Rotas protegidas

Exigem login.

Nada exposto

Chave fica no servidor.

RLS on

Confirme no banco.

Rate limit

Evita abuso de custo.

6

💳 Pagamentos com Stripe (freemium)

O que é

Mesmo um usuário logado pode chamar sua chave de IA sem limite (200 leads = 200 chamadas pagas). A solução é cobrar com Stripe num modelo freemium: um nível grátis com limite (ex.: 2 qualificações por dia) e um plano pago (ex.: $29/mês, ilimitado) via Stripe Checkout. Isso transforma o app num SaaS.

O que é?Freemium — grátis até um limite, pago para liberar o resto. Checkout — a tela de pagamento hospedada pelo Stripe. Price ID — o identificador do preço do produto. Webhook secret — a chave que valida que o aviso de pagamento veio mesmo do Stripe.

🎯 Objetivo: adicionar pagamentos com modelo freemium (em Plan Mode).

prompt (copie e rode em Plan Mode)
Quero adicionar pagamentos com Stripe ao qualificador de leads. O nível grátis
recebe <2> qualificações por dia. Passado isso, precisa assinar. O plano pago
custa <$29> por mês e dá qualificações ilimitadas. Quero usar o Stripe no fluxo
de pagamento. Me guie passo a passo para configurar a conta, criar o produto e
conectar o Stripe à Vercel e ao Supabase.

✅ Como verificar: a IA gera a página de preços (Grátis vs Pro), tabelas no banco e o cliente/servidor do Stripe. Comece no modo teste/sandbox do Stripe.

🎯 Objetivo: configurar produto, webhook e as 4 chaves do Stripe.

passos manuais (Stripe + Vercel + Supabase)
1. Stripe (modo teste) → Product catalog → New product:
   nome "", recorrente, mensal, <$29> → salvar.
2. Abra o produto → Pricing → copie o PRICE ID (guarde num bloco de notas).
3. Developers → API keys → copie publishable key e secret key.
4. Developers → Webhooks → Add endpoint:
   URL = /api/stripe-webhook  (use a URL EXATA que a IA der)
   Eventos: checkout.session.completed,
            customer.subscription.updated,
            customer.subscription.deleted
   → copie o WEBHOOK SECRET.
5. Supabase → SQL editor → rode a migration gerada (cria a tabela `subscriptions`).
6. Vercel → Settings → Environment Variables → adicione as 4 chaves
   (secret, publishable, price ID, webhook secret) → salvar → redeploy.

✅ Como verificar: na página de preços, assine o Pro → Checkout do Stripe → cartão de teste (validade futura, ex.: 10/27, qualquer CVC) → assinatura confirmada → uma nova linha aparece na tabela subscriptions do Supabase.

Por que aprender

O pagamento é o que transforma um app num produto: receita real e proteção contra abuso de custo. O webhook do Stripe é a peça que "destrava" o plano pago quando o pagamento confirma — e o webhook secret garante que esse aviso veio mesmo do Stripe, não de um impostor.

Conceitos-chave

Freemium

Grátis até o limite.

Checkout

Tela do Stripe.

3 eventos

Completed, updated, deleted.

4 chaves

No painel da Vercel.

7

🖥️ Frontend pra um workflow n8n (form → webhook)

O que é

O último build une os dois mundos do curso: dar uma cara de app a um workflow n8n. O exemplo é um gerador de orçamentos (entradas: descrição do projeto, horas estimadas, tipo de cliente → devolve um orçamento). Você cria um frontend que envia os dados ao webhook do fluxo e mostra a resposta. O truque no n8n: trocar o nó de form pelo Webhook trigger e o nó de saída pelo Respond to Webhook.

O que é?Respond to Webhook — um nó do n8n que devolve a resposta para quem chamou o webhook, para o frontend exibir. Placeholder — um valor provisório (ex.: a URL do webhook) que você substitui pelo real depois.

🎯 Objetivo: planejar o frontend que conversa com o webhook do n8n.

prompt (copie e rode em Plan Mode)
Me ajude a criar um CLAUDE.md para este projeto. O objetivo é construir um
frontend web para um workflow do n8n. O workflow é um gerador de orçamentos:
o usuário informa descrição do projeto, horas estimadas e tipo de cliente, e
recebe de volta um orçamento profissional. O frontend envia os dados para um
webhook do n8n e deve exibir a resposta. Use a skill de front-end design da
Anthropic. Me faça as perguntas de esclarecimento que precisar.

✅ Como verificar: a IA pergunta a stack, a URL do webhook (use um placeholder por enquanto) e o formato da resposta (ex.: JSON). Se o visual sair básico, peça: "A UI está muito simples. Garanta que está usando a skill de front-end design" e cole a skill de novo.

🎯 Objetivo: converter o n8n para webhook e ligar a URL real.

passos (n8n + Vercel)
No n8n:
1. Remova o PRIMEIRO nó (form) → adicione um Webhook trigger.
2. Remova o ÚLTIMO nó (saída) → adicione um "Respond to Webhook".
3. Reconecte ambos à lógica existente.
4. PUBLIQUE o workflow e copie a URL de produção do webhook.

[prompt] Quando o usuário clicar em "Gerar orçamento", chame este webhook.
Substitua o placeholder atual por ele: 

Na Vercel: Settings → Environment Variables → nova var N8N_WEBHOOK_URL =
 → salvar → redeploy.

✅ Como verificar: preencha o form (ex.: landing page / saúde / 40 h / enterprise) → "Gerar orçamento" → o n8n roda → o orçamento aparece no app. Use a URL de produção e o workflow precisa estar publicado.

Por que aprender

Este build conecta a automação visual (n8n) a uma interface de app de verdade — o formulário nativo do n8n funciona, mas a experiência é limitada e o acesso é restrito. Trocar form por webhook + "Respond to Webhook" é o padrão para dar a qualquer workflow uma cara amigável e compartilhável.

Conceitos-chave

Form → webhook

Troca o gatilho.

Respond to Webhook

Devolve a resposta.

Placeholder

URL provisória.

Publicar

URL de produção.

8

🪜 Iteração incremental (design → auth → pagamento)

O que é

Todo este módulo é um app que cresceu em camadas, partindo de um prompt de uma frase: app funcional → design → autenticação → pagamento → deploy. Você não precisa planejar tudo de antemão; entrega a v1 e adiciona recursos conforme a necessidade — uma boa prática de engenharia.

1app v1 2design 3auth + RLS 4segurança 5pagamento 6deploy comece pequeno, publique cedo, escale

Diagrama ilustrativo — uma camada por vez, testando a cada uma. O app começou como uma frase e virou um SaaS com auth e pagamento.

🎨 Dica: fuja do "look genérico de IA"

Saídas de IA se parecem porque o modelo padrão é o "design seguro". Combata isso: peça para usar a skill de front-end design; busque inspiração (galerias de design, bibliotecas de componentes); suba screenshots de referência para o projeto; e descreva o layout com precisão (cabeçalho fixo, logo à esquerda, CTA com brilho). Dê feedback específico ao iterar: "gostei de X, mude Y".

Por que aprender

Iterar em camadas mantém cada passo testável e reversível: se o pagamento quebra algo, você sabe que foi a última camada. Tentar montar tudo de uma vez gera um emaranhado impossível de depurar. Comece pequeno, faça backup antes de cada mudança, publique cedo e cresça — é o mesmo princípio que abre a trilha 1.

Você tem um app full-stack para construir com design, login e pagamento. Qual abordagem segue a boa prática deste módulo?

📌 Resumo do Módulo

Arquitetura — frontend (Vercel) + backend (Trigger.dev) que se comunicam; comece pelo CLAUDE.md.
Build — workflow em dev E prod; chamar a skill de design no frontend; testar local antes de publicar.
Conexão — env vars ligam as pontas; segredo no painel, nunca no chat; erro → devolver → redeploy.
Auth + RLS — Supabase para login; RLS protege os dados no banco; migration cria a tabela.
Segurança — auditoria como especialista: rotas, chaves, env vars, RLS; rate limiting contra abuso.
Stripe freemium — grátis até o limite, Pro mensal; produto, price ID, 3 eventos, webhook secret, 4 chaves.
Frontend pra n8n — form → webhook + Respond to Webhook; URL de produção em env var.
Iteração incremental — uma camada por vez, testando; comece pequeno, publique cedo, escale.

Você concluiu a Trilha 5! 🎉

Construiu três projetos end-to-end. Próximo passo natural: a Trilha 6 — Produção, Deploy & Segurança, para endurecer tudo isso com confiabilidade e monetização.