Vibe coding para copiar onboarding de concorrente sem clonar a tela

Martin jogou uma ideia no meio da live como se fosse um extra para fazer quando sobrasse tempo: "tirar print onboarding de outros aplicativos do mesmo estilo". O agente que lê o projeto dele devolveu a ideia com outra classificação. Fotografar o onboarding de um concorrente direto é o jeito mais barato de descobrir a lista de campos que o seu banco vai precisar ter, e é trabalho que vem antes da primeira tabela.

Martin constrói o Fumava, um app para ajudar as pessoas a parar de fumar. O projeto já tinha ambiente, marca e design system rodando no emulador, com ícone próprio, e nenhuma funcionalidade. Ele pediu ao agente orquestrador que lesse a pasta e dissesse quais eram os próximos passos, porque o roadmap que existia não estava claro para ele. A resposta trocou a ordem das duas próximas tarefas.

A ideia dos prints saiu da fila e virou caminho crítico

O agente concordou com a regra geral que estava no roadmap, banco antes de tela, e mostrou onde ela emperrava: "não dá para desenhar a tabela profile sem saber exatamente o que o Onboard pergunta". A ideia dos prints era do Martin, dita de passagem. O que o agente fez foi reclassificá-la.

Ou seja, sua ideia dos prints não é uma tarefa paralela.

Inverter a ordem cobra caro de um jeito específico. Se Martin fechasse o esquema do banco naquele dia e no seguinte percebesse que o onboarding precisa de mais uma pergunta, "você mexe no banco com app já lendo", e mexer em tabela com o app em cima dela é retrabalho que dava para não ter. O onboarding é o documento que diz quais colunas existem. Sem ele, o esquema é adivinhação.

A lista do que olhar separa isso de dar uma espiada no concorrente

O pedido do agente não parou em tirar prints. Veio com a lista do que olhar, escrita antes de o celular sair do bolso. Sem essa lista, você instala o app do concorrente, acha o fluxo bonito e volta sem nada aproveitável.

Ele pediu para fotografar a sequência inteira, desde abrir o app até bater na tela de pagamento, na ordem em que ela aparece, e para reparar em coisas específicas:

- quantas telas até a primeira pergunta - quais perguntas e em que ordem - em que momento aparece a cobrança, antes ou depois de mostrar o valor para o usuário - se pede login e quando - qual é a tela principal depois do onboarding

A lista de perguntas vira a lista de colunas. O momento da cobrança e a exigência de login viram decisão de fluxo e de conta. A recomendação veio com prazo e com motivo:

Minha recomendação vai tirar os print agora. É a única coisa que me destrava. Leva 30 minutos e evita construir um banco que vai ter que mudar.

Martin foi. Instalou no celular um app concorrente direto, do mesmo nicho, e fotografou o onboarding inteiro até chegar na tela de pagamento. "40 print do celular, 40 telas diferentes", ele contou ao voltar. Guardou tudo numa pasta e avisou ao agente que os arquivos estavam "na ordem, em ordem de como veio aparecendo para mim". Manter a ordem importa tanto quanto ter os arquivos, porque a sequência em que as perguntas aparecem é parte do que se está lendo ali.

O que o vibe coding extrai dos prints é a arquitetura de informação

A palavra copiar puxa para o lado errado. O que sai dos 40 prints é a arquitetura de informação do produto: quais dados ele pede, em que ordem e em que momento. Isso vira esquema de banco de dados, e para na porta da interface. Redesenhar a tela do concorrente seria outra coisa, e daria um app pior, porque o desenho é a parte que o usuário compara lado a lado e a parte que o dono do produto defende.

Ler o onboarding de quem já está publicado paga duas contas que uma sessão de vibe coding sozinha não paga. A sequência de perguntas de um app no ar já passou por usuário de verdade, muito mais gente do que você vai conseguir testar sozinho no emulador, e a ordem das telas dele é resultado de tentativa, não é chute. O que economiza mais tempo é o outro lado: o onboarding é a lista de campos do seu banco escrita em forma de tela. Adivinhar essa lista é o que faz você migrar tabela depois, com dado de usuário dentro. Foi o mesmo caminho de onboarding de cliente. O mesmo problema apareceu em vibe coding para deixar usuario corrigir escolha do onboarding. Foi o mesmo caminho de vibe coding para hard pay depois do onboarding.

Se você já leu por aqui quando vale clonar só a funcionalidade que viralizou, a diferença é de alvo: lá a pergunta é o que construir, aqui é o que perguntar.

Como rodar isso na sua próxima pausa

Essa tarefa cabe em qualquer dia porque não depende de mais ninguém e não ocupa uma tarde inteira, e foi por isso que ela entrou na frente de tudo.

Escreva a lista do que quer olhar antes de instalar o app do concorrente, no bloco de notas mesmo, porque depois de abrir o app você já está olhando com o olho errado. Passe pelo onboarding com o dedo no botão de print e vá até a tela de pagamento sem pular etapa. Depois entregue a pasta ao seu agente na ordem em que os arquivos foram gerados e peça a lista de campos que aquele fluxo implica, com o tipo de cada um. Essa lista é o rascunho do seu esquema.

A live acabou antes do desfecho. Com os prints em mãos, Martin e o agente começaram a definir os campos do onboarding do Fumava, o agente ficou escrevendo o documento de onboarding, e a transmissão terminou com o banco na nuvem ainda por criar. Trabalho cortado no meio assim só continua se o progresso ficar escrito em algum lugar que o agente leia depois, e é exatamente esse o problema de retomar o onboarding de onde parou na sessão seguinte. O que mudou foi a origem das decisões de banco: elas passaram a sair de um fluxo que já roda no mundo real. Dá para assistir à live e acompanhar a conversa inteira.

Trocar uma decisão de banco difícil de desfazer por uma tarefa de 30 minutos é o tipo de manobra que o vibe coding cobra de quem constrói sozinho, porque não tem time de produto do lado para avisar que a ordem está errada.