Você anuncia um app. Cria uma página. Coleta e-mails. Promete que vem algo empolgante.
Enquanto isso, alguém vê a mesma oportunidade, abre um agente de programação e começa a construir.
Quando você envia o e-mail de “Estamos quase prontos”, seus possíveis clientes talvez já estejam usando outra coisa.
Esse é meu problema com listas de espera na era do desenvolvimento com agentes. O tempo entre uma ideia e uma versão útil mudou. Não estou tão convencido de que os conselhos de lançamento acompanharam a mudança.
Se você pode entregar algo útil hoje, por que pedir que voltem depois?
A estratégia antiga tinha uma razão
Quando criar um produto exigia meses de engenharia, uma lista permitia aproveitar o interesse inicial: testar mensagens, recrutar usuários beta e reunir um público enquanto o software tomava forma.
Linear e Superhuman são exemplos conhecidos. A Linear selecionava usuários da lista e melhorava o produto com pequenos grupos. A Superhuman investia bastante na integração pessoal de novos usuários. As duas abordagens ajudavam a aprender com os clientes.
Mas essas estratégias surgiram antes dos agentes de programação atuais. Explicam a origem da prática; não demonstram que suas vantagens e custos continuam fazendo sentido.
Quando fica mais barato entregar um experimento funcional, enfraquece o argumento de coletar apenas manifestações de interesse.
Um e-mail indica que alguém gostou da sua promessa o suficiente para preencher um formulário. Uma pessoa usando seu app pode mostrar onde essa promessa falha.
Você também dá tempo aos concorrentes
Uma lista pública anuncia uma oportunidade antes que você necessariamente tenha conquistado um cliente.
Isso pesa mais em produtos cuja função principal é relativamente fácil de reproduzir. O anúncio descreve o problema, a demonstração esboça a solução e o número de inscritos revela interesse.
Um concorrente não precisa copiar todo o seu planejamento. Basta resolver o suficiente do problema do cliente para ser útil primeiro.
É um risco competitivo, não uma lei comprovada. Não encontrei pesquisas demonstrando que listas fazem startups perderem seus mercados de forma recorrente. Lançar primeiro também não garante vencer.
Ainda assim, prolongar deliberadamente o intervalo entre “Eu quero isso” e “Posso usar isso” merece atenção.
O problema do cliente está acontecendo agora. O calendário de lançamento é seu.
O que dizem os exemplos mais recentes?
Na própria retrospectiva, a Lovable descreve dois lançamentos malsucedidos em 2024, entradas graduais pela lista de espera e uma IA que ainda travava demais. Atribui a virada a melhorias no produto, mudança de marca e comunicação melhor. A lista existia antes; não foi suficiente para produzir a virada.
A Manus complica a declaração de que lançamentos restritos morreram. Começou testes por convite em março de 2025 e depois informou US$ 100 milhões em receita recorrente anual. Isso mostra sucesso comercial após um lançamento restrito. Não revela se a restrição causou o sucesso ou se abrir antes teria funcionado melhor.
Devemos usar o mesmo critério nos dois sentidos. Uma empresa bem-sucedida que usou uma lista não prova que a lista funcionou. Uma empresa que fracassou não prova que ela era o problema.
Convidar alguém para um produto é diferente
Há uma diferença importante entre coletar interesse numa ideia e controlar acesso a algo que já está sendo usado.
A Instinct ilustra o modelo de convites: sua página pública inclui um link para convidar um amigo. Isso não estabelece por que limita o acesso, mas aponta para outra interação: um usuário atual pode trazer outra pessoa para a experiência.
Parece mais crível quando o convite leva a um produto funcional.
Existem limites razoáveis. Talvez você só consiga atender poucos novos clientes por semana. Operar agentes pode custar caro. Talvez seja preciso observar falhas antes de admitir mais pessoas.
Convites também podem fabricar escassez. O mecanismo não resolve a questão. O motivo da restrição, sim.
A melhor defesa: encontrar clientes ainda dá trabalho
Desenvolver mais rápido não cria distribuição automaticamente.
Um relato recente ilustra isso. O fundador da Hado SEO informou ter coletado 80 e-mails e convertido cinco em clientes pagantes na semana do lançamento. Antes, ajudava potenciais clientes em comunidades e refinava a oferta. São resultados declarados pelo próprio fundador, mas descrevem conversão, não apenas um número grande de inscrições.
É um argumento legítimo para uma preparação curta. Você pode descobrir onde os clientes se reúnem, como descrevem o problema e se consegue alcançá-los.
Mas sobra uma pergunta: você aprenderia mais entregando a essas mesmas pessoas um produto pequeno que funciona?
À medida que construir fica mais rápido, essa alternativa se torna mais prática.
Faça a espera se justificar
Sou cético em relação a listas cujo objetivo principal é tornar desejável um app ainda indisponível.
Uma lista útil deveria corresponder a algo concreto: limite de capacidade, experimento com clientes, dependência ou limitação do produto que você está resolvendo. Deve haver um motivo para esperar e uma condição para entrar.
“Criar expectativa” é uma resposta muito mais fraca.
Antes de colocar aquele formulário, pense no que poderia entregar. Um fluxo de trabalho. Uma função útil. Uma versão limitada que faça algo bem.
Então você pode medir se as pessoas usam, voltam e se importam com as melhorias.
Se alguém pode lançar uma versão útil da sua ideia antes que você termine de criar expectativa, o que exatamente você está esperando?