Quando um produto vira dois: como dividir o seu app criado com IA sem começar do zero

Você começou com uma ideia. Você a descreveu ao seu criador de apps com IA, viu-o gerar as telas, ajustou as arestas e lançou algo de verdade. As pessoas começaram a usar. E aí, devagar no começo, um padrão apareceu no feedback: metade dos seus usuários queria uma coisa, a outra metade queria outra. Eles não estavam brigando pelo mesmo recurso. Estavam pedindo dois produtos diferentes.

Este é o momento em que muitos fundadores entram em pânico e começam um segundo projeto do zero. Eles não deveriam. Existe um jeito mais limpo de dividir um app de IA quando o seu único produto acaba sendo dois — e em geral ele mantém a maior parte do que você já construiu. Este post é sobre como reconhecer a divisão, quando fazê-la e os três formatos que ela tende a tomar.

Como você descobre que tem dois produtos

O sinal quase nunca tem cara de pedido de recurso. Tem cara de fricção.

Um app de produtividade que vi passar por isso tinha uma história clara. Ele era vendido como um “planejador pessoal”. Os usuários começaram a aparecer em dois sabores. Um grupo o usava para organizar a própria semana e o tratava como um caderno privado. O outro grupo tocava pequenas equipes e queria atribuir coisas a outras pessoas. Os dois estavam felizes o bastante para continuar usando o mesmo produto, mas cada lançamento agradava um grupo e irritava o outro. A equipe achava que tinha um problema de priorização de recursos. Na verdade, tinha um problema de marca. Tinha um app pessoal e um app de equipe compartilhando uma base de código, uma página inicial e uma página de preços.

Você vai saber que cruzou essa linha quando uma destas começar a ser verdade:

A sua landing page tem que esconder o pitch de verdade atrás de uma linguagem genérica porque dois públicos não vão acreditar nas mesmas palavras.
Todo recurso novo tem uma ressalva do tipo “mas para o outro tipo de usuário deveria funcionar diferente”.
As suas respostas de suporte começam a se ramificar: “se você está usando para si mesmo…” vs. “se você está gerenciando uma equipe…”.
Um número não trivial de usuários mantém duas contas separadas para manter os dois modos separados.

Se você está vendo duas ou mais dessas, você não tem um problema de recurso. Você tem uma divisão de produto esperando para acontecer.

Os três formatos de uma divisão

Você não precisa escolher um formato no primeiro dia. Em geral dá para tentar o mais leve primeiro e escalar. Mas é útil conhecer o cardápio antes de começar a descrever isso ao seu criador de apps com IA, porque as palavras que você usar vão moldar o que é gerado.

Formato 1: um app, duas portas

A versão mais leve. Você mantém uma base de código. Você adiciona uma pergunta na primeira execução — “Você está aqui para si mesmo ou para uma equipe?” — e usa a resposta para mostrar um conjunto diferente de páginas e uma navegação diferente. Mesmo armazenamento de dados. Mesmo login. Mesma cobrança. Só uma superfície diferente.

A maioria dos criadores de apps com IA lida bem com isso se você descrever como um “app de dois modos”. O que observar é que os dois modos não deveriam compartilhar telas com mostra-e-esconde condicional em todo lugar. Isso acaba parecendo um app bagunçado se fingindo de dois. Diga ao criador que as duas portas são separadas — páginas iniciais diferentes, páginas de configuração diferentes, estados vazios diferentes. As poucas telas que de fato se sobrepõem (configurações da conta, cobrança) podem ser compartilhadas.

Quando isto funciona: quando os dois públicos querem um enquadramento diferente mas os mesmos objetos subjacentes. O exemplo planejador-versus-equipe encaixa aqui. A coisa que você está agendando ainda é uma tarefa; só as regras em torno de atribuir, compartilhar e notificar mudam.

Quando isto não funciona: quando os dois públicos esperam objetos completamente diferentes. Um “portal de clientes” e uma “ferramenta interna de admin” quase não têm sobreposição, mesmo que pareçam ser sobre o mesmo negócio.

Formato 2: dois apps, um backend

O formato do meio. Você divide a frente do produto em dois apps separados — duas URLs, duas landing pages, dois fluxos de onboarding, duas tabelas de preço — mas ambos leem do mesmo banco de dados por baixo. Um cliente pode ter conta nos dois. Um admin pode ver dados dos dois.

Foi isso que recentemente fizemos na empresa que mantém este blog. Tínhamos um app tentando atender dois públicos: engenheiros avaliando a nossa plataforma de agentes, e criadores usando o nosso criador de apps com IA. Mesmo backend, mesma autenticação, mesmo banco de dados — mas o frontend tinha crescido duas cabeças, e a mensagem estava confusa. Nós o dividimos em dois apps de frontend, um para cada público. O backend ficou exatamente o mesmo.

Este formato é a resposta certa quando:

Os dois públicos compram por motivos diferentes.
Eles ficariam confusos ou desinteressados com o texto de marketing do outro público.
Os dados com que se importam têm, na maior parte, o mesmo formato, mas enquadrados de modo diferente.
Você não quer manter dois bancos de dados ou duas configurações de cobrança.

Diga ao seu criador de apps com IA que você quer um “segundo app de frontend que compartilha a API existente”. A maioria dos criadores de apps com IA modernos consegue montar um projeto irmão e apontá-lo para o seu backend existente. A armadilha a evitar: copiar e colar os componentes do primeiro app ao pé da letra e depois editar as duas cópias para sempre. Peça ao criador para extrair as partes compartilhadas (telas de autenticação, componentes de formulário comuns) para uma pequena biblioteca que os dois apps usem. Você vai poupar meses de correções duplicadas mais tarde.

Formato 3: dois apps, dois backends

A divisão mais pesada. Você de fato tem dois produtos. Eles não compartilham dados, não compartilham usuários e não deveriam compartilhar um roteiro. A jogada certa é separá-los por completo: bases de código separadas, bancos de dados separados, domínios separados.

Esta é a jogada certa com menos frequência do que as pessoas pensam. É tentadora porque parece limpa. A realidade é que dois apps completamente separados significam dois de tudo para manter rodando — dois pipelines de deploy, duas escalas de plantão, duas integrações de cobrança, duas documentações de ajuda. Não recorra a este formato a menos que os produtos genuinamente não se sobreponham. Um bom teste: se um usuário do produto A nunca seria um usuário do produto B, você provavelmente precisa do Formato 3. Se a maioria dos seus usuários poderia plausivelmente querer os dois, você quase certamente quer o Formato 2.

Quando você fizer isto com um criador de apps com IA, a jogada mais fácil é copiar o seu projeto existente como ponto de partida para o segundo, e então pedir ao criador para remover os recursos que não pertencem e adicionar os que pertencem. Não comece o segundo projeto de uma tela em branco. Você já aprendeu muito construindo o primeiro, e o criador de apps com IA vai captar esse contexto se você deixar.

O que fazer antes de dividir qualquer coisa

Antes de descrever a divisão ao seu criador de apps com IA, faça três coisinhas. Elas valem mais do que parecem.

Primeiro, escreva a nova página inicial de cada lado. Dois parágrafos cada. O pitch, o público, a única coisa que você quer que eles façam. Se você não consegue escrever duas páginas iniciais diferentes, você ainda não tem dois produtos de verdade — você só tem dois segmentos de um produto, e deveria resolver isso com mensagem, não com arquitetura.

Segundo, liste quais telas são compartilhadas e quais não são. Seja honesto. “O login é compartilhado. O onboarding é diferente. O painel é diferente. As configurações são, na maior parte, compartilhadas. A cobrança é compartilhada.” Essa lista vira o briefing que você entrega ao criador de apps com IA. Ela poupa muito vai-e-volta.

Terceiro, decida o que é igual por baixo. Mesmos usuários? Mesmos dados? Mesmos pagamentos? Cada “sim” te puxa para o Formato 1 ou 2. Cada “não” te puxa para o Formato 3. Não há resposta certa — só a resposta que combina com como o seu produto de fato funciona.

O que muda depois da divisão

Duas coisas ficam mais fáceis e uma fica mais difícil.

O marketing fica mais fácil. Cada app ganha o próprio pitch claro. Cada landing page consegue falar com um público sem rodeios. A sua taxa de conversão em geral sobe em pelo menos um lado, às vezes nos dois.

O onboarding fica mais fácil. Um usuário de primeira viagem cai numa página que é sobre ele, não numa página tentando ser sobre todo mundo.

O que fica mais difícil é manter as partes compartilhadas em sincronia. Se você corrige um bug no fluxo de login, quer que ele seja corrigido nos dois apps. Se você muda como a tela de cobrança fica, quer que os dois apps reflitam isso. A disciplina de que você precisa — e isso é verdade quer você esteja fazendo vibe coding com um criador de apps com IA, quer construindo com uma equipe de desenvolvedores humanos — é manter as partes compartilhadas genuinamente compartilhadas. Não duplique. Não bifurque. Ou extraia a tela compartilhada para uma pequena biblioteca que os dois apps usem, ou aceite que você tem dois apps de fato separados e assuma isso.

Uma pequena pergunta para encerrar

Se você apresentasse o pitch do seu app atual a cinco estranhos e cada um o descrevesse de um jeito diferente — mas em dois grupos distintos — você provavelmente já está convivendo com a divisão. A única pergunta é se você continua pagando o imposto de um produto confuso, ou faz o trabalho de ser honesto sobre ser dois.

Você não precisa decidir hoje. Mas da próxima vez que o seu criador de apps com IA perguntar “o que devo construir a seguir?”, considere que a resposta mais útil pode não ser um recurso novo. Pode ser uma nova porta de entrada.

Se isto fez sentido, você também pode gostar do nosso texto anterior sobre construir para a sua equipe vs construir para clientes — o mesmo sabor de decisão, um passo antes na vida do seu produto.