O protótipo vs. o produto: como saber quando o seu app criado com IA está de fato pronto
O seu app criado com IA funciona. Ele faz a coisa. Então por que parece que não está pronto? Um guia sem tecnicismos para a lacuna entre um protótipo funcional e algo pelo qual as pessoas de fato vão pagar.
Algumas semanas atrás, uma fundadora que conheço construiu um app de agendamento para terapeutas. A coisa toda levou quatro dias com um criador de apps com IA. Ele faz o que ela precisa: os terapeutas veem a agenda, os clientes marcam consultas, as confirmações saem por e-mail. Funciona.
Ela vem encarando isso há duas semanas e não lançou.
Quando perguntei por quê, ela disse: “Funciona, mas… não parece pronto.”
Perguntei o que ela mudaria. Ela disse: “Não sei. Esse é o problema.”
Este é o momento mais difícil de construir com um criador de apps com IA. A coisa é funcional, mas há uma lacuna entre “funcional” e “eu me sentiria confortável pedindo a pessoas reais que usem isto”. Entender essa lacuna — e saber de que lado dela você de fato está — é a diferença entre lançar e ficar preso para sempre na fase da voz na sua cabeça.
O que “pronto” de fato significa
Aqui está a distinção que importa: um protótipo é algo que você usa para testar uma ideia. Um produto é algo que você usa para resolver um problema.
O app de agendamento para terapeutas é um protótipo. Ele prova que o conceito funciona. Um terapeuta poderia usá-lo. Mas há dezessete coisinhas que o fazem parecer tosco:
- As confirmações por e-mail são cruas. Sem logo, sem marca personalizada, texto genérico.
- Os cancelamentos não enviam notificações. Os clientes simplesmente não aparecem.
- Não há lista de espera se um terapeuta está com a agenda lotada.
- O fluxo de cadastro não coleta as especialidades do terapeuta, então não há como filtrar por tipo de prática.
- Não há e-mail de lembrete enviado 24 horas antes da consulta.
Nenhuma dessas coisas quebra o app. Todas elas fazem um terapeuta real pensar: “Isto parece algo que montaram num fim de semana, não algo pelo qual estão me cobrando.”
Essa sensação é real, e importa. Um protótipo resolve o problema na teoria. Um produto o resolve na prática, para o humano de verdade que o usa.
Três perguntas que separam o protótipo do produto
Aqui está a parte difícil: você não tem como saber tudo o que está faltando. O seu criador de apps com IA também não tem. Então você precisa de três perguntas rápidas para descobrir de que lado da linha você está.
1. Você usaria isto para resolver o seu próprio problema?
Esta é honesta, porque você tem que de fato conviver com o seu próprio produto.
Se você é o fundador daquele app de agendamento para terapeutas, você o usaria para agendar as suas próprias consultas de terapia? Não “você poderia” — você de fato o usaria em vez de uma troca de e-mails ou de um Google Doc compartilhado?
Se a resposta é não, você não está pronto. Você sabe exatamente o que está errado — você sente toda vez que abre o app. Se a resposta é sim, você está mais perto.
A fundadora que mencionei passou pelo próprio cadastro de terapeuta. Ela travou no formulário (ele pedia informação demais antes de deixá-la marcar). Viu o e-mail de confirmação e achou que parecia amador. Começou a pensar em como a terapeuta dela receberia o e-mail e se ele acabaria no spam.
Ela não estava usando o próprio produto do jeito que um cliente pagante usaria. Quando usou, encontrou dez coisas para corrigir.
2. Você mostrou para três pessoas que não são você?
Falar com usuários em potencial é mais difícil que construir, e a maioria dos fundadores pula porque quer surpreender as pessoas no lançamento. Isso é um erro.
Você não precisa de um grupo focal. Você precisa de três pessoas parecidas com quem você acha que é o seu cliente. Para o app de terapeutas, são três terapeutas de verdade.
Eis o que você está procurando: onde elas ficam confusas? Onde hesitam? O que perguntam? Não “o que elas acham disto?” (as pessoas são gentis demais). Peça que de fato façam a coisa — marquem uma consulta, enviem um e-mail de confirmação, cancelem algo.
Quando a fundadora mostrou o app de terapeutas a três terapeutas, duas delas perguntaram: “Posso definir regras de quando estou disponível? Tipo, só atendo clientes novos às quintas, e não dobro agendamentos antes das 14h.” O app tinha um calendário, mas não regras. Ela tinha construído o protótipo para como ela achava que o agendamento funcionava, não para como os terapeutas de fato trabalham.
Isso é informação de produto. Você não tinha como adivinhar a partir de uma especificação.
3. O que quebraria se você desse isto a dez usuários reais?
Esta é a mais difícil porque exige que você realmente pense nos seus casos extremos.
Para o app de terapeutas:
- O que acontece se um cliente tenta marcar duas consultas no mesmo horário? (O app não verifica.)
- O que acontece se um terapeuta cancela uma consulta? Os clientes são notificados automaticamente? (Não.)
- E se o endereço de e-mail de um cliente está errado? Há como corrigir sem começar do zero? (Não.)
- E se um terapeuta tem um dia de doença e precisa fechar a agenda por uma semana? (Ela teria que apagar manualmente cada consulta.)
Essas não são falhas de software. O app não trava. Mas são cortezinhos de papel. Com dez usuários reais e casos extremos reais, você vai bater em todos eles na primeira semana.
Um produto lida com os casos extremos. Não com todos — algumas coisas podem esperar. Mas os que acontecem nas primeiras duas semanas com usuários reais, esses precisam funcionar.
Como decidir: o teste das três camadas
Use isto para descobrir onde você está:
Camada 1: fluxo central — O caminho feliz funciona? Um usuário consegue fazer a coisa principal para a qual o seu app foi projetado?
Para o agendador de terapeutas: sim. Alguém consegue se cadastrar, marcar uma consulta, receber uma confirmação. Funciona.
Camada 2: casos extremos do uso real — Você mostrou para três usuários de verdade. Eles bateram em algo para o qual você não construiu? Ficaram confusos em algum lugar?
Para o agendador de terapeutas: sim. As três terapeutas queriam disponibilidade baseada em regras. Uma ficou confusa porque o e-mail de confirmação parecia genérico demais. Uma tentou apagar consultas em lote e não conseguiu.
Camada 3: polimento e profissionalismo — Ele parece que você se importa? Ou parece que você o juntou às pressas?
Para o agendador de terapeutas: parece juntado às pressas. As confirmações por e-mail são cruas. Não há marca personalizada. Não há mensagem de erro se algo dá errado, então, se algo quebra, o usuário não faz ideia do que aconteceu.
Aqui está a heurística:
- As três camadas funcionando? Você é um produto. Lance.
- Camadas 1 e 2, mas não a 3? Você está 80% pronto. Gaste um dia em polimento.
- Camada 1 funcionando, camadas 2 e 3 não? Você é um protótipo. Não lance ainda.
- A camada 1 não está sólida? Você não está pronto. Continue construindo.
O app de terapeutas estava travado na fronteira entre a camada 1 e a camada 2. O fluxo central funcionava, mas terapeutas reais o achavam com peças faltando. Então a fundadora tinha uma escolha: gastar mais uma semana com o criador de apps com IA adicionando os recursos que os terapeutas de fato precisam, ou lançar com o que tinha e adicioná-los depois.
(Ela os adicionou. Levou três dias. Agora é um produto.)
A coisa que torna isto difícil
O motivo de tantos fundadores travarem aqui é que construir é divertido e lançar é assustador.
Construir é uma conversa com a sua ferramenta de IA. Você tem uma ideia, descreve, a ferramenta executa. Há um ciclo de feedback que leva minutos. Lançar é diferente. Você clica em publicar e, se algo está errado, humanos de verdade descobrem. Não há refazer.
Então a gente acha motivos para não lançar. “Não está polido o suficiente.” “Eu deveria adicionar mais um recurso.” “E se as fontes estiverem erradas?” E seis semanas depois, você ainda está em cima de algo que funciona mas não parece pronto, e você se convenceu de que é por causa das fontes.
Não são as fontes.
Em geral é que você não gastou tempo com um usuário real, ou construiu algo que fazia sentido na sua cabeça mas não encaixa direito em como pessoas reais trabalham. Isso é resolvível. Só exige admitir que você não sabe o que não sabe, e então ir falar com alguém que sabe.
O checklist de prontidão para o lançamento
Use isto. É curto e honesto.
- Eu mesmo o usei para fazer a tarefa real, e funcionou (não num jeito de modo demo, mas de verdade).
- Eu o mostrei para três pessoas que de fato o usariam, e corrigi as coisas que as confundiram.
- Todo erro que pode acontecer tem uma mensagem que diz ao usuário o que fazer a respeito (não “erro”, mas orientação de verdade).
- Eu ficaria bem se esta fosse a última versão por seis meses (ou seja: está completo o bastante para ser útil mesmo que eu nunca mais toque nele).
- Estou mais empolgado com o que vou aprender com usuários reais do que com adicionar mais recursos no vácuo.
Se você consegue marcar as cinco caixas, está pronto. Lance.
Se não consegue, não lance. Mas seja específico sobre o porquê. “Não parece pronto” não é um motivo. “Terapeutas de verdade precisam de regras de disponibilidade e eu ainda não construí isso” é um motivo. Isso é acionável. Isso é resolvível. Essa é a diferença entre estar travado e estar num caminho.
A fundadora do app de terapeutas o lançou ontem. Ela tem o primeiro cliente pagante. O produto não é perfeito, mas é real, e a cliente dela já está dizendo o que construir a seguir. É aí que você sabe que está pronto: não quando o app é perfeito, mas quando você está pronto para aprender o que “perfeito” de fato significa para as pessoas que o usam.