Um app não é um workflow invisível: ele tem um usuário do outro lado. O diagrama abaixo mostra o ciclo que se repete a cada interação — o navegador (frontend) faz uma requisição, o servidor (backend) processa e devolve uma resposta, e a tela se atualiza.
Diagrama ilustrativo — recriação conceitual do ciclo request/response, não uma captura de tela real.
🪟 Background vs visível
Até aqui o que você construiu rodava no fundo: workflows e scripts disparados por agenda ou evento, sem ninguém olhando. Um app é o oposto: ele é visível — tem uma interface com a qual pessoas interagem. Esta trilha vai do que roda invisível para um produto de verdade na internet, com design, autenticação e pagamento.
💡 A virada de chave
Um app full-stack é um frontend por cima do backend que você já sabe construir. A abordagem prática é começar simples — um site básico — e iterar adicionando features, em vez de planejar tudo de antemão.
- •Fundo: workflow/script sem interação visível.
- •Visível: uma interface que outras pessoas usam.
- •Projeto-âncora: um AI Lead Qualifier — da ideia ao app no ar.
✓ Pensa como produto
- ✓Começa por um site básico e cresce por features.
- ✓Assume que outras pessoas vão interagir com ele.
- ✓Trata o frontend como parte do produto, não enfeite.
✗ Armadilhas
- ✗Tentar planejar 100% das features antes de publicar.
- ✗Tratar um app como se fosse só um workflow no fundo.
- ✗Ignorar que agora existe um usuário do outro lado.
🎯 Dica prática
Comece pequeno e publique cedo. Um app simples no ar ensina mais do que um plano gigante na cabeça — e cada feature nova (design, login, pagamento) entra como uma camada por cima do que já funciona.
Workflow sem interface.
App com que se interage.
Frontend sobre backend.
Crescer por features.
🗺️ Frontend vs backend
O frontend é tudo o que o usuário vê — botões, imagens, formulários, textos, fontes, layout — e roda no navegador. O backend roda em um servidor: guarda a lógica, faz as requisições HTTP, chama APIs e conversa com o banco de dados. Você não precisa dominar cada detalhe técnico, mas precisa internalizar essa separação — ela é a base de tudo o mais sobre apps.
🖥️ Frontend (navegador)
- •Botões, formulários, imagens, textos.
- •Fontes, cores e layout — a UX.
- •O que o usuário toca e enxerga.
⚙️ Backend (servidor)
- •A lógica e as regras de negócio.
- •Requisições HTTP e chamadas de API.
- •Conexão com o banco de dados.
🧭 Por que apps diferem de workflows
Workflows rodam no fundo, sem interação visível. Apps exigem uma interface e interação em tempo real: alguém clica, espera, e vê o resultado. Por isso a UX — navegabilidade, legibilidade das fontes, clareza do layout — passa a fazer parte do produto.
🎯 Dica prática
Quando algo der errado, pergunte-se primeiro: isso é frontend (a tela não mostra) ou backend (a lógica não rodou)? Localizar de que lado está o problema é metade do diagnóstico.
Onde o frontend roda.
Onde o backend roda.
Parte do frontend.
O modelo mental-base.
🔄 Ciclo request/response
Todo app vive de um vai-e-vem contínuo entre o que o usuário vê e o que acontece nos bastidores. Esse vai-e-vem é o ciclo request/response: o usuário clica, uma requisição parte para o servidor, o servidor processa, e a resposta volta para atualizar a tela.
As quatro etapas do ciclo
O usuário clica
Uma ação no frontend (enviar um formulário, apertar um botão) dispara o ciclo.
A requisição vai ao servidor
O navegador envia os dados ao backend, que recebe a requisição.
O servidor processa
Salva dados, chama uma API ou roda a lógica — o trabalho de bastidores.
A resposta atualiza a UI
O backend devolve a resposta e o frontend redesenha a tela com o resultado.
⏱️ Interação em tempo real
É esse ciclo que separa um app de um workflow no fundo: alguém está esperando do outro lado. Cada interação é uma volta completa do ciclo — e a velocidade dessa volta faz parte da experiência.
🎯 Dica prática
Ao descrever o app para a IA, pense em termos de ciclo: "quando o usuário envia o formulário, manda X ao backend, processa Y e mostra Z na tela". Isso dá à IA a forma exata da interação.
Início do ciclo.
Frontend → servidor.
Lógica, API, banco.
UI atualiza.
🎨 Tips de design
Sites gerados por IA tendem a ter uma "cara de IA": layouts, cores, gradientes e heros padronizados. Isso acontece porque a IA puxa para um "design funcional" seguro e previsível, sugerido da mesma forma para todo mundo. Criar algo original exige direcioná-la conscientemente — com referências, vocabulário preciso e feedback específico.
✗ A "cara de IA"
- ✗"Construa uma landing page" → resultado genérico.
- ✗Gradientes e heros idênticos a mil outros sites.
- ✗Feedback vago → ciclos infinitos de iteração.
✓ Direção consciente
- ✓Usar uma skill de design dedicada.
- ✓Dar referências (sites, screenshots) concretas.
- ✓Dizer o que gostou e o que mudar — e por quê.
💡 Por que outputs de IA se parecem
A IA otimiza para um resultado "seguro": o que costuma funcionar para a maioria. Sem direção, ela entrega o denominador comum. A boa notícia é que ela responde muito bem a referência e vocabulário — é exatamente isso que os próximos dois tópicos exploram.
🎯 Dica prática
Na primeira vez que vir a interface, anote em voz alta o que gostou e o que não gostou — e por quê. Esse comentário cru é o melhor insumo de feedback para a próxima iteração.
O default da IA.
Mostra o que quer.
Descreve com precisão.
Específico, não vago.
🖼️ Skill de design & referências
O atalho de maior impacto visual é uma skill de design dedicada: basta pedir à IA para usá-la ao gerar a UI e o resultado melhora drasticamente, mesmo em um único prompt. Combine isso com referências — clonar um site que você gosta, inspirar-se em galerias e usar screenshots como exemplo.
Três formas de elevar a UI
Pedir a skill de design
Ao gerar a interface, peça à IA para usar a skill de front-end design. É a mudança de maior efeito por menor esforço.
Clonar / inspirar-se em galerias
Encontre um site que você admira e peça para clonar o design; busque inspiração em galerias e bibliotecas de componentes.
Usar screenshots como referência
Suba uma imagem ao projeto e peça "algo parecido com isto" — a IA usa a referência visual como norte.
🔎 Onde buscar referência
Galerias de design e bibliotecas de componentes são minas de inspiração: layouts testados, paletas e padrões prontos. Em vez de descrever do zero, mostre o que quer — referência vale mais que adjetivos.
🎯 Dica prática
Mesmo num prompt único, ativar a skill de design faz uma diferença enorme. Se quiser ir além, junte a skill com uma referência visual — o resultado vira sob medida.
Maior impacto.
Copie um site bom.
Inspiração pronta.
Referência por imagem.
🗣️ Linguagem de prompt de design
Descrever a interface com precisão é o que transforma um pedido genérico em um design intencional. Em vez de "faça bonito", você nomeia layout, componentes e tom visual — e, ao iterar, dá feedback específico em vez de "está errado".
# Layout Header fixo: logo à esquerda, links de nav à direita. Botão de CTA com glow azul no canto direito. # Hero Texto grande e bold, subtítulo curto, um CTA primário. # Tom visual Escuro, premium, com um acento âmbar e bastante respiro.
✓ Descreva com precisão
- ✓Layout: posição de header, nav, hero, seções.
- ✓Componentes: cards, botões, formulários, estados.
- ✓Tom visual: paleta, peso de fonte, densidade.
✗ Evite vago
- ✗"Deixe bonito" / "moderno" sem detalhe.
- ✗"Está errado" em vez de dizer o que e por quê.
- ✗Mudar tudo de uma vez sem isolar o que não foi.
🎯 Dica prática
Ao iterar, use a fórmula "gostei de X, mas mude Y porque Z". Feedback assim é acionável; "não gostei" obriga a IA a adivinhar e gera mais voltas do que conserto.
Onde cada coisa fica.
Cards, botões, forms.
Paleta e peso.
Gostei / mude / porquê.
🚀 Build do AI Lead Qualifier
O projeto-âncora é um app full-stack de qualificação de leads: o backend (workflow) roda no Trigger.dev e o frontend no Vercel, conectados para que qualquer pessoa com a URL use o workflow. A meta é ir de um prompt simples a um app publicado rapidamente.
Do prompt ao app publicado
Planejar em Plan Mode
Descreva o app (backend no Trigger.dev, frontend no Vercel) e deixe a IA gerar o CLAUDE.md e a estrutura base antes de codar.
Gerar workflow + config do Trigger.dev
A IA cria o workflow de qualificação, as instruções de deploy e o trigger.config.ts; cole o project ID/reference.
Deploy do backend (dev + produção)
Faça deploy da task nos ambientes de desenvolvimento e produção; adicione a chave da API de IA como env var no Trigger.dev (idealmente chaves separadas).
Gerar e publicar o frontend no Vercel
Gere a UI com a skill de design e faça deploy no Vercel — o site fica acessível de qualquer lugar, com auto-deploy a cada push.
📊 O resultado
Um formulário que envia os dados da empresa → a IA analisa → exibe um score (ex.: 68/100, "lead morno"), um resumo, o detalhamento do score e os próximos passos sugeridos — com a execução correspondente aparecendo nos runs do Trigger.dev.
⚠️ Atenção
- ✗Não cole secret keys no chat — pergunte onde encontrá-las e configure você mesmo nas env vars.
- ✗Não esqueça de promover a task ao ambiente de produção (não só dev).
Backend / workflow.
Frontend publicado.
CLAUDE.md + base.
Resultado para o usuário.
🔗 Conectar frontend ↔ backend
Com o backend no Trigger.dev e o frontend no Vercel, falta ligá-los. A conexão é feita por variáveis de ambiente: você adiciona a secret key do Trigger.dev como env var no Vercel, e o frontend passa a falar com a lógica. Cada push no GitHub dispara um deploy automático — o site fica sempre atualizado.
✓ Como conectar
- ✓Pegar a secret key do Trigger.dev (perguntando onde ela está).
- ✓Adicioná-la como env var no Vercel e redeployar.
- ✓Confiar no auto-deploy a cada push no GitHub.
✗ Não faça
- ✗Colar a secret key no chat ou no código versionado.
- ✗Esquecer de redeployar depois de adicionar a env var.
- ✗Confundir ambiente de dev com o de produção.
🎯 Dica prática
Pense nas env vars como a "tomada" entre frontend e backend: o código nunca contém o segredo, ele só lê de uma variável que vive na plataforma. Trocar a chave é trocar a variável — sem mexer no código.
Auto-recuperação (opcional): como o frontend no Vercel se conecta ao backend no Trigger.dev?
📌 Resumo do Módulo
Próximo Módulo:
4.2 — Produção Real: Auth, Segurança, Pagamentos & Integração