🟡 Construindo Frontends & Apps

A diferença entre o que roda invisível no fundo (workflows, scripts) e o que é visível ao usuário — um app, com uma interface com a qual pessoas interagem.

É a virada de chave da trilha: sair da automação invisível para um produto que outras pessoas usam.

Fundo vs interface; app full-stack; começar simples e iterar por features.

Frontend é tudo que o usuário vê (botões, formulários, fontes, layout), rodando no navegador; backend roda no servidor e guarda a lógica, as chamadas de API e o banco.

É o modelo mental que sustenta tudo o mais sobre apps — você não precisa dominar cada detalhe, mas precisa internalizar essa separação.

Navegador vs servidor; UX (navegabilidade, legibilidade, clareza); separação de responsabilidades.

O ciclo contínuo de troca: o usuário clica → uma requisição vai ao servidor → o servidor processa (salva dados, chama uma API, roda lógica) → a resposta volta → o frontend atualiza a tela.

Entender esse vai-e-vem explica por que apps precisam de interface e interação em tempo real, ao contrário de workflows que rodam no fundo.

Requisição → processamento → resposta → atualização da UI; interação em tempo real.

Técnicas para criar sites bonitos e originais, evitando o visual genérico que sites gerados por IA tendem a ter (layouts, cores, gradientes e heros padronizados).

Um app com cara de produto transmite credibilidade; o resultado "seguro e previsível" da IA passa despercebido.

Por que outputs de IA se parecem; prompts genéricos geram resultados genéricos; feedback específico.

Usar a skill de design para elevar a UI; clonar/inspirar-se em sites de galerias; subir screenshots de referência e pedir algo parecido.

É o atalho de maior impacto visual — uma skill de design muda o resultado mesmo em um único prompt.

Front-end design skill; galerias de inspiração; bibliotecas de componentes; referência por imagem.

Descrever layout, componentes e tom visual com precisão (ex.: header fixo com logo à esquerda, links à direita, CTA com glow azul, hero com texto grande e bold), e dar feedback específico ao iterar.

Vocabulário concreto evita o ciclo infinito de "está errado" — você fala o que gostou e o que mudar.

Layout/componentes/tom; feedback do que gostou e desgostou; iteração dirigida.

O build ponta a ponta de um app full-stack de qualificação de leads: backend no Trigger.dev, frontend no Vercel, conectados — do prompt simples ao app publicado.

É o projeto-âncora que amarra os conceitos num app real e acessível por URL.

CLAUDE.md + estrutura base; deploy dev e produção; resultado: score, resumo e próximos passos.

Ligar o frontend ao backend via chaves/variáveis de ambiente no Vercel (a secret key do Trigger.dev), com deploy automático a cada push no GitHub.

É o que faz a interface conversar com a lógica — e o que mantém o site sempre atualizado.

Secret key como env var; nunca colar no chat; auto-deploy via GitHub.

Um app sem login deixa qualquer pessoa com a URL disparar o workflow e consumir os seus tokens de IA — você paga pelo uso dos outros.

Autenticação protege uso e dados; é o primeiro passo antes de deixar o app aberto em produção.

Risco do app aberto; proteger uso e dados; usuários com seus próprios dados.

Adicionar login/cadastro usando o Supabase como provedor de banco e autenticação: criar o projeto, definir a senha do banco (distinta da senha de login) e escolher a região.

Um provedor pronto entrega autenticação e banco sem você montar tudo do zero.

Project URL + publishable key como env vars no Vercel; senha do banco ≠ senha de login.

Regras que vivem dentro do banco para isolar os dados entre usuários — mesmo que haja um bug no frontend, ninguém vê os dados de outro.

É uma camada extra de segurança que não depende do código da interface estar perfeito.

Isolamento por linha; defesa em profundidade; ativar RLS na tabela.

Rodar no SQL editor do Supabase a migração gerada pela IA (ex.: criar a tabela de leads) e configurar a URL do app (Vercel) e a redirect URL na configuração de auth.

Sem o esquema no banco e as URLs corretas, o login não completa o fluxo de volta ao app.

SQL editor; tabela criada por migração; URL do app + redirect URL.

Pedir à IA para atuar como especialista em segurança e checar rotas protegidas, nenhuma chave exposta no frontend, segredos só em env vars e RLS ativo.

Uma auditoria explícita pega vulnerabilidades antes que cheguem à produção.

Rotas protegidas; sem chaves expostas; segredos em env; RLS verificado.

Adicionar pagamentos com Stripe num modelo freemium: um tier grátis limitado (ex.: 2 qualificações/dia) e um tier pago (assinatura) via Stripe Checkout.

Completa a transição de "só um workflow" para um app que pode gerar receita e limitar o consumo.

Tier grátis vs pro; assinatura recorrente; Checkout.

Criar o produto recorrente, copiar o price ID, pegar as chaves (publishable + secret), criar o webhook com os eventos certos e rodar a migração da tabela de assinaturas.

São as quatro peças que ligam o pagamento ao seu app e mantêm o estado da assinatura.

Price ID; quatro chaves; eventos de checkout/assinatura; tabela de subscriptions.

Conectar um workflow n8n a um frontend trocando o nó de formulário por um Webhook (trigger) e o nó final por "Respond to Webhook", ligando via env var no Vercel.

É o padrão para dar uma interface bonita a qualquer workflow n8n e abri-lo por URL.

Trocar primeiro e último nó por webhooks; URL de produção; env var no Vercel.

A recap da jornada: o app começou como um prompt de uma frase e cresceu por camadas — design → autenticação → pagamento.

Boa engenharia é incremental: começar pequeno, publicar cedo e escalar conforme a necessidade, sem planejar tudo de uma vez.

Camadas; publicar a primeira versão; crescer por features.