💬 Product Sentence: A Frase que Define Tudo
Se voce nao consegue descrever seu produto em uma frase, voce nao entende seu produto. Isso nao e simplificacao excessiva. E clareza. Toda grande empresa que existe pode ser descrita em uma frase: "Um buscador que organiza a informacao do mundo" (Google), "Uma rede que conecta profissionais" (LinkedIn), "Um marketplace de hospedagem entre pessoas" (Airbnb).
A Product Sentence nao e marketing. E uma ferramenta de pensamento. Ela forca voce a responder quatro perguntas em sequencia: o que e, para quem, qual problema resolve, e como resolve. Se voce nao consegue preencher os quatro campos, tem lacunas na sua ideia que precisam ser resolvidas antes de escrever uma linha de codigo.
Conceito Principal: O Template
Cada campo tem uma funcao critica:
Tipo de app
Define a categoria e cria expectativas imediatas. "Uma plataforma SaaS", "Um app mobile", "Uma extensao de navegador", "Um dashboard web". O usuario ja sabe o que esperar.
Usuario especifico
NAO e "todo mundo". Quanto mais especifico, melhor. "Freelancers de design", "donos de restaurantes com ate 3 unidades", "professores de ensino medio". Especificidade gera foco.
Problema especifico
O verbo importa. "Organizar", "automatizar", "monitorar", "simplificar". O problema deve ser algo que o usuario sente no dia a dia, nao algo que voce imagina que ele tem.
Mecanismo principal
O "como" do seu produto. E aqui que entra a IA, automacao, ou qualquer tecnologia diferencial. "Atraves de chatbots com IA", "atraves de analise automatica de dados", "atraves de templates pre-configurados".
Exemplos Reais: Bons vs Ruins
Ruim:
"Um app de IA para empresas."
Problema: vago demais. Que tipo de app? Que empresas? Que IA? O que faz?
Bom:
"Uma plataforma SaaS que ajuda pequenas empresas a automatizar atendimento ao cliente atraves de chatbots treinados com dados da propria empresa."
Claro: SaaS + pequenas empresas + atendimento + chatbots customizados.
Ruim:
"Uma rede social para criadores de conteudo com marketplace, lives, assinaturas e cursos."
Problema: escopo infinito. Isso sao 4 produtos diferentes em 1 frase.
Bom:
"Um dashboard web que ajuda freelancers de marketing a gerar relatorios de performance para clientes atraves de integracao automatica com Google Analytics e Meta Ads."
Especifico: dashboard + freelancers de marketing + relatorios + integracao de dados.
Dica Pratica: O Teste do Elevador
Leia sua product sentence em voz alta. Se a pessoa do outro lado nao entender o que seu produto faz em 10 segundos, a frase precisa ser reescrita. Teste com alguem que nao e da area tech. Se sua mae (ou equivalente nao-tecnico) entender, voce acertou.
Outra tecnica: escreva 5 versoes diferentes da frase. Compare. A mais curta e especifica que ainda transmite a ideia completa e geralmente a melhor.
Fazer
- ✓Preencher todos os 4 campos do template
- ✓Ser especifico sobre o usuario-alvo
- ✓Testar a frase com pessoas nao-tecnicas
- ✓Escrever multiplas versoes e comparar
Evitar
- ✗Dizer que e "para todo mundo"
- ✗Listar 5 features na frase do produto
- ✗Usar jargao tecnico na descricao
- ✗Pular essa etapa ("vou definir depois")
🚦 User Flow Principal: Do Login ao Resultado
Um produto sem user flow definido e como uma cidade sem ruas: tem edificios bonitos, mas ninguem sabe como chegar de um lugar ao outro. O user flow e o mapa que descreve exatamente o que o usuario faz, em que ordem, e que resultado obtem em cada passo.
Para um MVP, voce precisa definir UM fluxo principal. Nao tres, nao cinco. Um. Esse fluxo e o caminho mais curto entre "o usuario chegou no seu produto" e "o usuario recebeu valor". Tudo no seu MVP existe para suportar esse caminho. Se uma tela ou feature nao esta nesse fluxo, ela nao deveria estar na v1.
Conceito Principal: O Fluxo em 5-7 Passos
Todo SaaS segue uma estrutura similar. O que muda e o conteudo de cada passo, nao a estrutura:
Chegada: Usuario acessa a landing page. Entende o que o produto faz em 5 segundos. Decide testar.
Cadastro: Sign up rapido (Google OAuth ou email/senha). Zero fricao. Nenhum formulario de 15 campos.
Onboarding: O usuario ve o dashboard pela primeira vez. Entende onde estao as coisas. Sabe o proximo passo.
Acao Principal: O usuario executa a acao central do produto. Esse e o momento de verdade. Se o seu produto e um gerador de relatorios, ele gera o primeiro relatorio aqui.
Resultado: O usuario recebe valor. Ve o output, baixa o arquivo, recebe a resposta. Esse e o "aha moment".
Time to Value: A Metrica que Importa
"Time to Value" (TTV) e o tempo entre o usuario criar a conta e receber o primeiro resultado util. Para SaaS modernos, o benchmark e menos de 5 minutos. Para apps com IA, o padrao e ainda mais agressivo: o primeiro resultado deve aparecer em menos de 60 segundos apos a acao principal.
TTV ideal para SaaS B2B (Notion, Linear, Vercel)
TTV esperado para o resultado de IA (ChatGPT, v0, Midjourney)
dos usuarios abandonam apps que nao entregam valor em 5 minutos (Mixpanel, 2025)
MVPs de sucesso tem 1 fluxo principal, nao 5 (YC Startup School)
Dica Pratica: Como Apps com IA Diferem
Em apps tradicionais, o valor vem do dado que o usuario armazenou. Em apps com IA, o valor vem do resultado que a IA gera. Isso muda o fluxo radicalmente: a primeira interacao com a IA deve acontecer o mais cedo possivel no fluxo.
Fluxo errado:
Login > Configurar perfil > Adicionar dados > Configurar preferencias > Finalmente usar a IA
Fluxo correto:
Login > Ver a IA em acao imediatamente > Customizar depois
Mostre o poder da IA primeiro. Peca informacoes depois. O usuario precisa sentir o valor antes de investir tempo configurando.
Fazer
- ✓Definir um unico fluxo principal com max 7 passos
- ✓Colocar a acao de IA o mais cedo possivel
- ✓Medir time to value (meta: < 5 min)
- ✓Desenhar o fluxo antes de codar
Evitar
- ✗Criar 5 fluxos diferentes na v1
- ✗Esconder a IA atras de 10 passos de configuracao
- ✗Pedir informacoes antes de mostrar valor
- ✗Ter um fluxo com mais de 7 passos
📱 Lista de Telas (Max 5 para v1)
Cinco telas. Esse e o limite para sua v1. Nao dez, nao quinze. Cinco. Cada tela e uma unidade de trabalho: design, implementacao, testes, responsividade. Cada tela adicionada multiplica a complexidade do projeto. E com Vibe Coding, e tentador gerar tela atras de tela porque parece rapido. Mas geracao rapida nao significa manutencao rapida.
As cinco telas essenciais cobrem o fluxo completo do usuario: chegar, entrar, ver o panorama, fazer a acao principal, e ajustar configuracoes. Qualquer coisa alem disso e feature creep disfarada de "necessidade".
Conceito Principal: As 5 Telas Essenciais
Landing Page
A primeira impressao. Headline claro que explica o produto, sub-headline com o beneficio principal, CTA unico (sign up ou try free), e talvez um screenshot ou demo. Nao e uma pagina de 15 secoes. E uma pagina que converte.
Informacao: o que faz, para quem, CTA, prova social (opcional na v1)
Auth (Login + Register)
Uma tela, nao duas. Toggle entre login e register. OAuth social (Google, no minimo) + email/senha. Formulario minimo: email, senha, e um botao. Nao peca nome, empresa, cargo e telefone no cadastro.
Informacao: email, senha, botao OAuth, link para alternar login/register
Dashboard
O hub central. Mostra o panorama geral: metricas de resumo (3-4 cards), acesso rapido a acao principal, e lista dos ultimos itens/atividades. Sidebar ou top nav para navegacao. O dashboard deve responder: "o que esta acontecendo?" e "o que eu devo fazer agora?"
Informacao: cards de resumo, link para acao principal, atividade recente, nav
Core Feature (Tela Principal)
A tela onde a magia acontece. Se seu produto e um chatbot, essa e a tela de conversa. Se e um gerador de relatorios, essa e a tela de geracao. Essa tela e o coracao do seu produto e deve receber a maior parte da atencao em design e implementacao.
Informacao: varia por produto. E a tela que implementa a product sentence.
Settings / Profile
Nome, email, foto, senha, preferencias basicas, e na v1 um botao de logout e talvez delete account. Nao precisa de 15 tabs. Uma pagina simples com as configuracoes essenciais.
Informacao: dados do perfil, alterar senha, preferencias basicas, logout
Mobile-First ou Desktop-First?
Essa decisao afeta toda a construcao. A regra e simples: se o seu usuario vai usar no trabalho (B2B, SaaS de produtividade), comece por desktop. Se vai usar no dia a dia (B2C, consumo rapido), comece por mobile.
Desktop-First
- Dashboards e analytics
- Ferramentas de produtividade
- Admin panels
- Ferramentas de desenvolvimento
Mobile-First
- Apps de consumo rapido
- Social / comunicacao
- Conteudo / entretenimento
- Ferramentas pessoais
Dica Pratica: Descreva Cada Tela em 1 Paragrafo
Para cada uma das 5 telas, escreva um paragrafo descrevendo: o que o usuario ve, o que ele pode fazer, e que informacao esta presente. Esse paragrafo se torna o prompt perfeito para pedir a IA gerar a tela.
Exemplo de descricao:
"Tela de Dashboard: o usuario ve 3 cards no topo (total de conversas este mes, tempo medio de resposta, satisfacao do cliente). Abaixo, uma lista das 5 conversas mais recentes com preview. Na sidebar esquerda, menu com: Dashboard, Conversas, Configuracoes. Header com nome do usuario e avatar."
Fazer
- ✓Limitar a v1 a exatamente 5 telas
- ✓Descrever cada tela em 1 paragrafo completo
- ✓Decidir mobile-first vs desktop-first cedo
- ✓Investir mais tempo na core feature (tela 4)
Evitar
- ✗Criar telas "porque e facil com IA"
- ✗Ter telas sem funcao clara no fluxo
- ✗Separar login e register em 2 telas
- ✗Comecar pelo design bonito antes do fluxo
🚧 Limites e Restricoes Tecnologicas
Vibe Coding faz construir parecer magico. Mas magia tem custos. Cada API tem rate limits. Cada servico gratis tem limites de uso. Cada modelo de IA cobra por token. Cada deploy tem limites de banda. Se voce nao mapear essas restricoes antes de comecar a construir, vai descobrir quando for tarde demais: quando o usuario esta usando e o servico cai.
Este topico nao e sobre limitar sua ambicao. E sobre construir com os olhos abertos. Saber quanto custa cada chamada de API, quantos usuarios o free tier suporta, e quando voce vai precisar pagar e a diferenca entre um projeto sustentavel e um que morre no primeiro pico de uso.
Conceito Principal: Mapa de Restricoes
API Rate Limits e Custos de IA
| Servico | Free Tier | Custo Apos |
|---|---|---|
| OpenAI GPT-4o | $5 credito inicial | ~$2.50/1M tokens input |
| Claude Sonnet | $5 credito inicial | ~$3/1M tokens input |
| Supabase | 500MB DB, 1GB storage | $25/mes (Pro) |
| Vercel | 100GB banda, 1000 builds | $20/mes (Pro) |
| Neon (Postgres) | 0.5GB, 1 projeto | $19/mes (Launch) |
Latencia e Experiencia do Usuario
Chamadas de IA nao sao instantaneas. Um request para GPT-4o leva 2-10 segundos dependendo do tamanho. Isso muda como voce desenha a UX:
- -Sempre mostre um loading state (spinner, skeleton, progress bar)
- -Use streaming quando possivel (resposta aparece token por token)
- -Cache respostas que nao mudam (evita chamadas repetidas)
- -Defina timeouts (15-30s max) para nao travar a UI
Budget Planning: Quanto Custa Rodar um SaaS com IA
A conta que ninguem faz antes de comecar: se cada usuario faz 10 interacoes por dia, e cada interacao custa ~$0.005 em tokens, 100 usuarios = $50/mes so em IA. Adicione hosting, banco de dados e dominio:
MVP com 0-10 usuarios: tudo no free tier (Vercel + Supabase + creditos iniciais de IA)
10-100 usuarios: custos de IA + possivel upgrade de DB. Ainda viavel para indie.
100-1000 usuarios: escala real. Precisa de monetizacao para cobrir custos.
custo medio por interacao de IA (GPT-4o mini / Claude Haiku). Faca a conta com seu volume.
Dica Pratica: Stack Recomendada para MVP 2026
Se voce esta comecando e quer o caminho de menor fricao com custos controlaveis:
Frontend: Next.js 14+ (App Router) + Tailwind CSS
Backend/DB: Supabase (auth + Postgres + storage em um so lugar)
IA: OpenAI API ou Anthropic API (modelo mais barato para v1: gpt-4o-mini ou claude-haiku)
Deploy: Vercel (gratis ate ~1000 deploys/mes)
Dominio: Qualquer registrador (~R$40/ano para .com.br)
Custo total para MVP: $0 (usando free tiers + creditos iniciais)
Fazer
- ✓Calcular custo por usuario antes de construir
- ✓Usar modelos de IA baratos na v1 (mini/haiku)
- ✓Implementar cache e rate limiting desde o inicio
- ✓Anotar limites dos free tiers que voce usa
Evitar
- ✗Usar GPT-4 para tudo sem controlar custo
- ✗Ignorar rate limits ate receber erro 429
- ✗Construir sem loading states para chamadas de IA
- ✗Deixar a conta de infra pra "resolver depois"
📅 Cronograma de Build com IA
Um dos maiores erros de builders iniciantes e nao ter um cronograma. "Vou construindo e vejo" e a receita para scope creep, burnout e abandono. Com IA acelerando a construcao, voce precisa de um plano mais rigido, nao menos. Porque a tentacao de "adicionar so mais uma coisa" e constante quando gerar codigo e rapido.
O cronograma realista para um MVP construido com Vibe Coding e 3 dias de trabalho focado (ou 1 semana em ritmo normal). Nao 3 meses. Nao 6 sprints. Tres dias. Se voce nao consegue construir a v1 em 3 dias com IA, o escopo esta grande demais.
Conceito Principal: O Plano de 3 Dias
Dia 1: Foundation (Fundacao)
Manha (4h): Setup do projeto (create-next-app, Supabase, env vars, Git init). Configurar auth (Google OAuth + email). Criar layout base (sidebar, header, footer). Deploy inicial no Vercel (mesmo vazio, ja funciona).
Tarde (4h): Banco de dados: criar as tabelas principais (max 3-4 tabelas). Tela de login/register. Tela de settings basico. Primeiro commit funcional.
Checkpoint: app rodando, auth funcionando, layout base pronto, deploy no ar.
Dia 2: Features (Construcao)
Manha (4h): Dashboard com dados reais (queries ao banco, cards de resumo). Integracao com API de IA (endpoint, streaming, tratamento de erros). Core feature v1 (a tela principal do produto).
Tarde (4h): Iterar na core feature (UX, edge cases). Adicionar loading states e tratamento de erros. Testes basicos (pelo menos para a funcao principal). Deploy atualizado.
Checkpoint: produto funcional. Um usuario poderia usar e receber valor.
Dia 3: Polish + Ship (Lancamento)
Manha (4h): Landing page (headline, sub-headline, CTA, 1 screenshot). Responsividade (testar mobile). Fix de bugs encontrados no dia 2. Revisao de seguranca (checklist do Modulo 1.6).
Tarde (4h): Deploy final. Testar fluxo completo como usuario novo. README basico. Compartilhar com 3-5 pessoas para feedback inicial. Documentar o que falta para v2.
Checkpoint: produto no ar, acessivel por link, primeiros usuarios testando.
Estimativas Realistas com IA
A aceleracao com IA nao e uniforme. Algumas tarefas ficam 5x mais rapidas, outras continuam no mesmo ritmo. Entender essa distribuicao evita frustracao:
mais rapido: boilerplate, componentes UI, CRUD, configuracao, testes unitarios, documentacao
mais rapido: integracao de APIs, logica de negocio moderada, queries complexas
mesmo ritmo: debugging complexo, decisoes de arquitetura, otimizacao de performance
mais lento se: voce nao entende o codigo gerado e precisa debugar output incorreto da IA
Dica Pratica: Buffer para Debug
Reserve 30% do tempo de cada dia para debug e correcoes. Codigo gerado por IA vai ter problemas. Isso nao e pessimismo, e realismo baseado em dados. Se voce planeja 8 horas de features, reserve 2-3 horas para corrigir o que nao funciona.
A pior situacao e chegar no Dia 3 com o Dia 2 incompleto porque voce subestimou o tempo de debug. Se sobrar tempo (improvavel na v1), use para melhorar UX, nao para adicionar features.
Fazer
- ✓Definir checkpoints claros para cada dia
- ✓Reservar 30% do tempo para debug
- ✓Deployer no Dia 1 (mesmo incompleto)
- ✓Cortar features se estiver atrasado, nao o prazo
Evitar
- ✗Planejar sem deadlines fixos
- ✗Gastar Dia 1 inteiro em design
- ✗Deixar deploy pro ultimo dia
- ✗Estender o prazo em vez de cortar escopo
📑 Exercicio: Documento Final do Produto
Este e o exercicio mais importante de toda a Trilha 1. Tudo que voce aprendeu nos modulos 1.1 a 1.7 converge aqui em um unico documento: o blueprint do seu SaaS. Este documento e o que voce vai usar como referencia em todas as proximas trilhas. Sem ele, voce entra na Trilha 2 (Arquitetura) sem saber o que esta construindo.
Reserve 30-45 minutos para completar este exercicio com atencao. Nao apresse. Cada secao que voce preencher agora sao horas que voce economiza depois. Um produto bem definido e um produto que a IA consegue construir com menos iteracoes, menos bugs e menos retrabalho.
Documento do Produto: 6 Secoes
Secao 1: Product Sentence
Escreva a frase unica que define seu produto usando o template do Topico 1:
Teste: alguem de fora entenderia o que e so lendo essa frase?
Secao 2: User Flow Principal
Descreva o caminho do usuario em 5-7 passos do Topico 2:
Passo 1: [Como o usuario chega]
Passo 2: [Como se cadastra]
Passo 3: [O que ve primeiro]
Passo 4: [Acao principal - onde a IA brilha]
Passo 5: [Resultado/valor entregue]
Teste: o time to value e menor que 5 minutos?
Secao 3: As 5 Telas
Para cada tela do Topico 3, escreva 1 paragrafo descrevendo o que o usuario ve e faz:
Tela 1 - Landing: [descreva]
Tela 2 - Auth: [descreva]
Tela 3 - Dashboard: [descreva]
Tela 4 - Core Feature: [descreva em detalhe]
Tela 5 - Settings: [descreva]
Teste: cada paragrafo poderia ser usado como prompt para gerar a tela com IA?
Secao 4: Stack Tecnica e Limites
Defina sua stack e liste restricoes do Topico 4:
Frontend: [framework + CSS]
Backend/DB: [servico + tipo de banco]
IA: [API + modelo escolhido]
Deploy: [plataforma]
Limite de custo mensal: [valor]
Custo estimado por usuario: [valor]
Secao 5: Lista de Exclusao
Liste pelo menos 7 coisas que a v1 NAO vai ter. Essa lista e tao importante quanto a lista do que vai ter:
NAO vai ter na v1:
1. [feature excluida e razao]
2. [feature excluida e razao]
3. ...
Teste: se alguem sugerir adicionar qualquer item desta lista, voce vai dizer nao?
Secao 6: Cronograma de 3 Dias
Adapte o plano do Topico 5 para o seu produto especifico:
Dia 1 - Foundation: [o que voce vai fazer manha e tarde]
Dia 2 - Features: [o que voce vai fazer manha e tarde]
Dia 3 - Polish + Ship: [o que voce vai fazer manha e tarde]
Teste: cada dia tem um checkpoint claro? Se o Dia 2 atrasar, o que voce corta?
Por que Este Documento Muda Tudo
Na Trilha 2 (Arquitetura), voce vai usar a Secao 4 (stack) para configurar o projeto. Na Trilha 3 (Construcao), vai usar as Secoes 2 e 3 (fluxo e telas) como prompts diretos para a IA. Na Trilha 4 (Agentes), vai conectar a Secao 1 (product sentence) ao comportamento do seu agente. Nas Trilhas 5 e 6, vai usar o cronograma e limites para planejar deploy e operacao.
Cada secao deste documento alimenta uma trilha inteira. Sem ele, voce vai improvisar. Com ele, voce tem um mapa completo.
Dica Pratica: Use a IA para Revisar o Documento
Depois de preencher as 6 secoes, use este prompt para a IA revisar:
Prompt de revisao final:
"Revise este documento de produto para um MVP construido com Vibe Coding. Analise:
1. A product sentence e clara e especifica o suficiente?
2. O user flow tem time to value menor que 5 minutos?
3. As 5 telas sao suficientes para o fluxo descrito?
4. A stack e adequada para o tipo de produto?
5. A lista de exclusao e agressiva o suficiente?
6. O cronograma de 3 dias e realista?
Aponte inconsistencias e sugira melhorias especificas."
Este e o ultimo passo antes de entrar na Trilha 2. Quando voce iniciar a Arquitetura, abra este documento e use cada secao como input para as decisoes tecnicas.
Fazer
- ✓Completar todas as 6 secoes antes de seguir
- ✓Pedir para a IA revisar o documento
- ✓Compartilhar com alguem para feedback
- ✓Salvar em local acessivel (vai usar nas trilhas 2-6)
Evitar
- ✗Pular para Trilha 2 sem completar o documento
- ✗Preencher superficialmente ("depois eu detalho")
- ✗Nao definir a lista de exclusao
- ✗Fazer o documento mas nunca consultar de novo
Resumo do Modulo 1.7 - Fim da Trilha 1
Voce completou a Trilha 1: Mentalidade e Metodo. Seu SaaS esta definido, documentado e pronto para ser construido. Aqui esta o que voce consolidou neste modulo final:
Proximo: Trilha 2 - Arquitetura
Na Trilha 2 voce vai transformar o documento do produto em codigo real: setup do projeto, estrutura de pastas, banco de dados, autenticacao e deploy inicial. Traga o documento que voce criou neste exercicio. Ele e o input para tudo que vem a seguir.