MÓDULO 2.3

🛠️ Construindo seu Primeiro App

Do briefing ao primeiro resultado funcional. Como definir o que construir, escrever prompts eficazes, interpretar o resultado e salvar versões sem perder progresso.

7
Tópicos
40
Minutos
Zero
Pré-requisito
Prático
Tipo
1

🎯 Definindo o que construir

O maior erro de quem começa com vibe coding não é escrever o prompt errado — é tentar construir a coisa errada. Aplicativos ambiciosos demais, cheios de features, para um público vago. A regra de ouro é: comece menor do que você acha que deveria.

🔬 O framework de definição

1.
Quem usa? Seja específico: "dono de pet shop" é melhor que "pessoas que têm animais"
2.
Qual é o problema? Uma frase: "donos de pet shop perdem agendamentos porque anotam no papel"
3.
Qual é a solução mínima? A menor coisa que resolve o problema: "app para agendar consultas e enviar lembrete por WhatsApp"
4.
O que NÃO está no escopo? Liste o que vai ficar para depois: relatórios, integração com estoque, app mobile

💡 A armadilha da feature envy

Todo fundador começa querendo construir o produto completo de uma vez — e aí nunca lança. O melhor produto é aquele que está no ar, sendo usado por pessoas reais, recebendo feedback. Uma feature funcionando vale mais que dez planejadas.

2

📝 Escrevendo o briefing

O briefing é o documento que você escreve antes de abrir qualquer ferramenta. Funciona como uma receita de bolo: quanto mais detalhada, menos improviso na hora de executar — e menos retrabalho depois.

📋 Template de briefing

NOME DO APP: [nome simples e descritivo]

USUÁRIO PRINCIPAL: [quem vai usar]

PROBLEMA QUE RESOLVE: [em uma frase]

FUNCIONALIDADES (3 no máximo):

1. [funcionalidade 1]

2. [funcionalidade 2]

3. [funcionalidade 3]

ESTILO VISUAL: [moderno, simples, colorido, etc.]

COR PRINCIPAL: [verde, azul, etc.]

NÃO INCLUIR: [o que fica para depois]

✅ Exemplo preenchido

NOME DO APP: AgendaPet

USUÁRIO PRINCIPAL: Dono de pet shop com 1-3 funcionários

PROBLEMA QUE RESOLVE: Perdem agendamentos porque controlam no papel

FUNCIONALIDADES:

1. Cadastrar cliente e pet com dados básicos

2. Agendar consulta com data/hora e serviço

3. Ver agenda do dia em tela simples

ESTILO VISUAL: Simples e limpo, fácil de usar no celular

COR PRINCIPAL: Azul

NÃO INCLUIR: Integração WhatsApp, pagamentos, estoque

3

💬 O primeiro prompt — Template que funciona

O prompt inicial é a primeira coisa que você manda para a ferramenta de vibe coding. Um bom prompt de abertura define o tom de todo o projeto. Use o template abaixo como ponto de partida.

📝 Template de primeiro prompt

Crie um aplicativo web chamado [NOME] para [USUÁRIO].


O app resolve o seguinte problema: [PROBLEMA EM UMA FRASE].


Funcionalidades necessárias:

1. [FUNCIONALIDADE 1]

2. [FUNCIONALIDADE 2]

3. [FUNCIONALIDADE 3]


Estilo visual: [ESTILO], com cor principal [COR]. Interface simples e intuitiva, funciona bem no celular.


Não inclua por enquanto: [LISTA DO QUE FICA PARA DEPOIS].

✅ Exemplo aplicado (AgendaPet)

Crie um aplicativo web chamado AgendaPet para donos de pet shop com 1-3 funcionários.


O app resolve o seguinte problema: eles perdem agendamentos porque controlam tudo no papel ou no WhatsApp.


Funcionalidades necessárias:

1. Cadastrar clientes e seus pets com nome, telefone e tipo do animal

2. Agendar serviços com data, hora, tipo do serviço e funcionário responsável

3. Ver a agenda do dia em uma tela clara com os horários


Estilo visual: simples e limpo, fácil de usar no celular, com cor principal azul. Sem detalhes desnecessários.


Não inclua por enquanto: integração com WhatsApp, sistema de pagamento, controle de estoque.

💡 Por que esse template funciona

Ele dá contexto (quem usa, qual problema), escopo claro (3 funcionalidades no máximo), estilo visual (evita perguntas sobre design) e o que NÃO incluir (a parte mais importante — evita que a IA adicione complexidade desnecessária).

4

👁️ Interpretando o resultado

A ferramenta gerou o primeiro resultado. Agora vem uma etapa que muitos não-técnicos pulam: avaliar o que foi gerado de forma estruturada. Não olhe para o código — você não precisa entendê-lo. Olhe para o comportamento.

✓ Como avaliar bem

  • ✓Teste cada funcionalidade que você pediu
  • ✓Use como se fosse um usuário real
  • ✓Tente encontrar o que quebra
  • ✓Veja se a interface é intuitiva
  • ✓Cheque no celular e no desktop

✗ Erros comuns

  • ✗Tentar ler e entender o código
  • ✗Aceitar o resultado sem testar
  • ✗Pedir tudo de uma vez no segundo prompt
  • ✗Desistir porque ficou diferente do esperado
  • ✗Mostrar para clientes antes de testar

📊 Checklist de avaliação rápida

□As funcionalidades que pedi estão presentes?
□O fluxo principal funciona sem erro?
□A interface é fácil de entender sem explicação?
□Aparece bem no celular?
□Há algo quebrado ou que não funciona?
5

🔄 Pedindo ajustes

O primeiro resultado raramente é o resultado final. O processo de vibe coding é iterativo — você pede, avalia, ajusta, e repete. A chave é saber como pedir ajustes de forma eficaz para que a ferramenta entenda exatamente o que mudar.

Pedidos de ajuste simples (design)

"Mude o botão de salvar de azul para verde"
"Deixe a fonte maior, está difícil de ler"
"Adicione um espaço maior entre os campos do formulário"
"Mova o menu para a parte de cima da tela"

Pedidos de ajuste complexos (funcionalidade)

"Quando o usuário salvar um agendamento, mostre uma mensagem de confirmação"
"Adicione uma opção de cancelar agendamento com confirmação antes"
"Mostre os agendamentos de hoje em ordem de horário, do mais cedo para o mais tarde"

Como descrever um erro

"Quando clico em Salvar, nada acontece. O formulário deveria ser limpo e mostrar o agendamento na lista."
"A tela fica em branco depois que faço login. Deveria mostrar a agenda."

💡 A fórmula de um bom pedido

[O que acontece agora] + [O que deveria acontecer]

Exemplo: "Quando clico em Salvar, o formulário não é limpo [o que acontece agora]. Depois de salvar, o formulário deveria ficar vazio para cadastrar o próximo agendamento [o que deveria acontecer]."

6

🧪 Testando funcionalidades

Testar não é opcional — é a parte mais importante do processo. Antes de mostrar para qualquer pessoa, você precisa quebrar o seu próprio produto. Isso parece contraintuitivo, mas é o que separa produtos que sobrevivem ao contato com usuários dos que causam vergonha.

🔨 Como testar como um usuário real

1.
Fluxo principal: Execute a ação mais importante do começo ao fim, sem desvios. Ex: cadastrar → agendar → ver na agenda.
2.
Tente quebrar: Deixe campos obrigatórios em branco, use datas inválidas, clique em botões várias vezes seguidas, feche e reabra.
3.
Teste no celular: A maioria dos seus usuários vai acessar pelo celular. Se não funcionar bem no celular, não está pronto.
4.
Peça para alguém usar: Sem dar explicações, coloque o link na mão de alguém e peça para usar. Observe o que trava.

⚠️ Nunca pule o teste

A IA pode gerar código que parece correto mas tem comportamentos inesperados em situações de borda. Um campo que aceita qualquer texto quando deveria aceitar só números. Uma ação que funciona uma vez mas quebra na segunda. Esses problemas só aparecem testando — nunca lendo o código.

7

💾 Salvando versões — O conceito de snapshot

Imagine que você está editando um documento importante. Antes de fazer uma mudança grande, você salva uma cópia com outro nome. Se a mudança estragar tudo, você volta para a cópia. Em vibe coding, isso se chama snapshot — e salva você de horas de retrabalho.

No Lovable

  • • Clique no ícone de relógio no topo da interface
  • • Veja o histórico de versões
  • • Clique em qualquer versão para restaurar
  • • Dê nome às versões importantes ("versão com login")

No Bolt.new e outros

  • • Use o histórico de conversas como referência
  • • Exporte o código antes de mudanças grandes
  • • Abra a ferramenta em outra aba com a versão antiga
  • • Faça screenshots do estado que está funcionando

💡 Quando salvar uma versão

  • • Antes de pedir qualquer mudança grande
  • • Quando o app está funcionando bem pela primeira vez
  • • Antes de adicionar uma nova funcionalidade
  • • Quando você vai mostrar para alguém
  • • Antes de tentar corrigir um bug complexo

✅ Resumo do Módulo 2.3

✓
Defina antes de construir — usuário, problema, 3 funcionalidades máximo, o que NÃO inclui
✓
Escreva o briefing — documento de uma página antes de abrir qualquer ferramenta
✓
Use o template de prompt — contexto + funcionalidades + estilo + o que não incluir
✓
Avalie o comportamento, não o código — teste como um usuário real, sem olhar para o código
✓
Peça ajustes com precisão — "o que acontece agora" + "o que deveria acontecer"
✓
Salve snapshots — sempre antes de mudanças grandes, quando está funcionando bem

Próximo Módulo:

2.4 — 🎯 Do Protótipo ao Produto: como transformar um app que funciona em um produto pronto para usuários reais

← Módulo Anterior Próximo Módulo →