MÓDULO 2.2

🧩 Construindo apps: do conceito ao app funcional

Um site só mostra; um app reage. Aqui você pega um site simples e o transforma num app de verdade — com banco de dados, login, formulário que salva e tudo no ar — construindo em camadas pequenas e testáveis.

6
Tópicos
~60
Minutos
Inter.
Nível
Prática
Tipo
0% 0 de 6
🖥️ Front-end o salão (o que se vê) ⚙️ Back-end a cozinha (processa) 🗄️ Banco a despensa ✉️ e-mail 🔐 login publicar → no ar ▲ no ar um app = front-end + back-end + banco + integrações — e depois, publicado

Conteúdo detalhado

1

🧱 Site vs app: o que você está realmente construindo

Um site é, em geral, só leitura: a pessoa chega, vê o conteúdo e vai embora — nada fica guardado. Um app reage a quem usa: recebe dados, guarda esses dados, lembra de você e dispara ações. É a diferença entre um cartaz na parede e um caixa eletrônico.

O que é:

As quatro peças de um app: front-end (o que se vê), back-end (o que processa), banco de dados (onde se guarda) e integrações (serviços de fora).

Por que aprender:

Saber a peça certa para cada problema evita pedir a coisa errada ao Claude e gastar tempo à toa.

Conceitos-chave:

Front-end · back-end · banco de dados · integração · determinístico vs probabilístico.

✓ É hora de virar app quando…

  • Você precisa guardar dados de quem usa (e-mails, respostas).
  • Cada pessoa tem que entrar e ver a própria área.
  • Algo deve acontecer depois (enviar e-mail, registrar pedido).

✗ Ainda é só um site quando…

  • A pessoa só lê o conteúdo e nada fica salvo.
  • Não há login nem áreas privadas.
  • Nenhuma ação acontece após a visita.

🍽️ Analogia do restaurante

O front-end é o salão (mesas, cardápio). O back-end é a cozinha (onde o pedido é processado). O banco é a despensa e o livro-caixa. As integrações são os fornecedores e a maquininha de pagamento — serviços de fora que o restaurante chama quando precisa.

2

🗄️ O banco de dados: onde os dados moram

Sem banco, todo dado coletado se perde quando a aba fecha. Com banco, vira um ativo seu. Pense no Supabase como uma planilha turbinada: as tabelas são abas, as linhas são registros e as colunas são campos — só que confiável, com uma API pronta e falando direto com o Claude Code.

O que é:

Um lugar confiável para gravar registros — nomes, e-mails, respostas de formulário, contas de usuário.

Por que aprender:

O banco é o "esqueleto firme" determinístico do app — salvar um e-mail tem que salvar aquele e-mail, sempre igual.

Conceitos-chave:

Tabela · linha · coluna · "ponto de registro" (a fonte da verdade) · conector/MCP.

1

Abra os conectores

No Claude Code, clique no botão de "+" e depois em "conectores".

2

Conecte o Supabase

Ache o Supabase na lista e clique em conectar — abre uma janela para autorizar.

3

Crie o projeto e confirme

Peça ao Claude para criar um projeto novo. Depois confirme em supabase.com que ele apareceu.

Conectar e criar o banco

Conecte este projeto a um banco de dados Supabase. Crie um projeto novo para este app.
3

🔐 Login e contas: capturar dados com segurança

Duas peças andam juntas: o formulário, que transforma cada resposta numa linha da tabela, e a autenticação, que identifica cada pessoa (cadastro, login, logout). Sem login, todo mundo vê tudo; com login, você tem áreas privadas e conteúdo por usuário — tudo gerenciado pelo Supabase.

O que é:

Formulário → tabela (campo vira coluna) somado ao sistema de contas: cadastro (sign-up), login (sign-in) e sessão.

Por que aprender:

É o salto de "site que mostra" para "app que coleta e protege" — o começo de valor de verdade.

Conceitos-chave:

Campo → coluna · validação · sessão · "área autenticada".

✓ Faça no teste

  • Peça cadastro e login com senha obrigatória, gerenciados no Supabase.
  • Em Authentication → Sign-in providers, desligue a confirmação de e-mail só durante os testes.
  • Considere "entrar com Google" — é o padrão hoje e facilita a vida de quem usa.

✗ Não esqueça antes de ir ao ar

  • Deixar a confirmação de e-mail desligada em produção (enche o banco de cadastros falsos).
  • Esquecer de testar logout e novo login com a mesma senha.
  • Liberar áreas privadas sem sessão válida.

Autenticação básica

Adicione cadastro e login com senha obrigatória, tudo autenticado e gerenciado no Supabase.
Depois do login, leve a pessoa para um dashboard simples no mesmo estilo do site.

Original (EN):

Add sign-up and login with a required password, fully authenticated and managed in Supabase.
After login, take the user to a simple dashboard in the same style as the site.
4

💬 Construir em camadas: pedir, testar, repetir

Você não escreve tudo de uma vez. Você conversa em camadas: "adiciona um formulário", testa, "agora salva no banco", testa, "agora deixa mais bonito", testa. Cada pedido é pequeno e verificável — é assim que se constrói com confiança.

O que é:

Descrever uma mudança pequena em linguagem natural, ver o resultado e ajustar — em vez de tentar tudo de uma vez.

Por que aprender:

Mudanças pequenas são fáceis de testar e corrigir. É o que mantém o projeto sob controle.

Conceitos-chave:

Loop pedir → testar → feedback · descrever o "o quê", não o "como" · contexto enxuto (/compact, fork).

1

Faça um pedido só

Descreva uma única mudança pequena e espere o Claude terminar.

2

Abra o app e confira

Teste de verdade. Não confie no "feito" — veja com os próprios olhos.

3

Dê feedback e repita

Descreva o que está errado ou faltando e mande o próximo pedido. Repita até gostar.

🧠 Dica prática: cuide do contexto

Conversa longa demais piora as respostas. Quando o histórico ficar pesado, use /compact. Para um experimento isolado sem misturar tudo, renomeie a conversa atual e crie um fork a partir dela.

5

✅ Testar de ponta a ponta

"Parece funcionar" não basta. Você testa o fluxo completo como uma pessoa de verdade — preenche, envia — e só então olha o Supabase para ver o registro exato na tabela. A tela diz "enviado"; o banco diz a verdade.

O que é:

Percorrer o app como usuária(o) e, depois, conferir manualmente no Table Editor do Supabase.

Por que aprender:

Ver "enviado com sucesso" na tela não prova que salvou. Confirmar no banco é o que dá certeza.

Conceitos-chave:

Teste de ponta a ponta · fonte da verdade · conferência manual.

1

Use o app de verdade

Preencha o formulário, crie uma conta de teste e faça login como qualquer pessoa faria.

2

Abra o Table Editor

No Supabase, vá ao Table Editor e procure a linha exata que você acabou de criar.

3

Confirme o dado certo

O nome e o e-mail que você digitou têm que estar lá — campo por campo. Só então está validado.

⚖️ Determinístico vs probabilístico

Modelos de linguagem são probabilísticos: a mesma pergunta pode dar respostas diferentes. Um app precisa de partes determinísticas — salvar um e-mail tem que salvar aquele e-mail, sempre igual. Por isso a verdade mora no banco, não na geração de texto.

6

🚀 Publicar no ar (deploy)

Um app só no seu PC não serve a ninguém. Publicar é "subir" o código para a internet, com um endereço que qualquer pessoa abre. É o passo que torna o app real — e fecha o ciclo conceito → app funcional.

O que é:

Colocar o app em produção na Vercel, com um endereço público que qualquer pessoa abre.

Por que aprender:

Publicar é o que transforma um experimento local em algo que outras pessoas realmente usam.

Conceitos-chave:

Deploy · ambiente de produção · "no ar" · checklist pré-lançamento.

Publicar no ar

Quando estas mudanças estiverem prontas, publique e coloque o app no ar na Vercel.

Original (EN):

When these changes are ready, deploy and publish the app live on Vercel.
Indo mais fundo (opcional): o checklist antes de divulgar

Antes de mandar o link para alguém: confirme em vercel.com que o deploy saiu, abra o endereço gerado e refaça o fluxo completo num navegador anônimo. E o mais importante: reative a confirmação de e-mail no Supabase — você só a tinha desligado para testar.

Auto-checagem (opcional): como você tem certeza de que um lead foi salvo?

✏️ Exercícios

1. Conecte e crie a tabela (fácil)

Conecte o Supabase ao seu projeto e crie a tabela leads. Critério: a tabela aparece no Table Editor com as colunas certas.

2. Capture um lead real (fácil)

Adicione o formulário e envie uma resposta de teste. Critério: a linha com o nome e e-mail que você digitou aparece na tabela leads.

3. Adicione login (médio)

Implemente cadastro e login com senha. Critério: você cria conta, sai e entra de novo com a senha — e vê uma área que só aparece depois do login.

4. Itere com feedback (médio)

Faça pelo menos três melhorias pequenas (uma por pedido), testando entre elas. Critério: cada mudança foi descrita em uma frase, testada e confirmada antes da próxima.

5. Publique (médio)

Coloque o app no ar na Vercel. Critério: você abre o endereço público num navegador anônimo e o fluxo completo funciona.

⌨️ Prompts prontos

Use estes como ponto de partida e adapte ao seu app. Quando o prompt for canônico, deixamos também o original em inglês. O banco completo está na Biblioteca → Prompts.

Formulário que salva no banco

Adicione um formulário com nome, e-mail e "qual seu maior desafio hoje?".
Quando enviarem, salve as respostas no Supabase, na tabela `leads`.

Pedir feedback antes de construir

Antes de implementar, me diga o que você precisa de mim e quais decisões você vai tomar.
Faça perguntas de esclarecimento se algo estiver ambíguo.

Iterar com base numa tela

Aqui está um print da tela atual. Há espaço demais acima e abaixo da imagem.
Ajuste para caber bem, sem cortar o conteúdo importante.

Deixar o Claude executar em vez de pedir para você (canônico)

Sempre que possível, execute você mesmo as tarefas (CLI, scripts) em vez de me pedir para fazer manualmente.
Só me peça quando for algo que só eu posso fornecer (login, chave, decisão).

Original (EN):

Whenever possible, run the tasks yourself (CLI, scripts) instead of asking me to do them manually.
Only ask me for things only I can provide (login, key, decision).

⚠️ Erros comuns

  • Tentar tudo de uma vez. Um único pedido gigante gera um resultado difícil de testar e corrigir. Quebre em passos pequenos.
  • Não validar no banco. Ver "enviado com sucesso" na tela não prova que salvou. Abra o Table Editor e confira a linha.
  • Esquecer de reativar a confirmação de e-mail. Desligar para testar é ok; deixar desligado em produção enche o banco de cadastros falsos.
  • Esperar respostas idênticas da IA. Modelos são probabilísticos. Para o que precisa ser sempre igual, confie no banco e na lógica.
  • Deixar o contexto inchar. Conversa longa demais piora as respostas. Use /compact e considere um fork para frentes paralelas.

Resumo do módulo

Site vs app — site mostra; app guarda dados e reage. As quatro peças: front-end, back-end, banco e integrações.
Banco + login — o Supabase guarda os dados (a fonte da verdade) e gerencia cadastro, login e sessão.
Construir em camadas — pedido pequeno → teste → feedback → próximo, com contexto enxuto.
Testar e publicar — valide no banco de ponta a ponta e suba o app no ar na Vercel.

Checklist de conclusão

  • ☐ Sei explicar a diferença entre site e app e nomear as quatro peças (front, back, banco, integrações).
  • ☐ Conectei o Supabase ao meu projeto e criei um projeto novo de banco.
  • ☐ Tenho um formulário que salva respostas reais na tabela leads.
  • ☐ Confirmei o registro diretamente no Table Editor do Supabase.
  • ☐ Adicionei cadastro e login com senha e testei criar conta, sair e entrar.
  • ☐ Construí de forma incremental: pedido pequeno → teste → feedback → próximo.
  • ☐ Publiquei o app na Vercel e validei o fluxo completo (com a confirmação de e-mail reativada).

Próximo módulo:

2.3 — Construa qualquer coisa: além de sites e apps, automações e ferramentas sob medida