Especialistas em Startups Discutem Fazer Coisas que Não Escalam
- Aisha Washington
- há 1 dia
- 8 min de leitura
Fundadores em estágio inicial costumam ser incentivados a pensar em escala desde o começo. Perguntam-lhes como seus sistemas atenderão milhões de usuários, como a aquisição de clientes se tornará repetível e como as operações vão se expandir sem que os custos cresçam no mesmo ritmo. São perguntas legítimas — mas os especialistas em startups desta discussão da Y Combinator argumentam que elas muitas vezes são feitas cedo demais.
Os participantes retomam o influente ensaio de Paul Graham, “Do Things That Don’t Scale”, e explicam por que sua mensagem continua central para construir uma empresa do zero. Por meio de exemplos que incluem Airbnb, Fleek, Stripe, Algolia, Instacart e DoorDash, eles defendem que o esforço manual não é apenas um compromisso temporário aceitável. Quando usado de forma deliberada, é uma maneira poderosa de testar a demanda, entender os clientes e descobrir quais partes de um negócio realmente valem a pena escalar.
Por Que o Mundo das Startups Precisava de um Manual Diferente
Segundo os participantes, o entusiasmo do Vale do Silício por sistemas escaláveis cresceu em parte ao observar empresas de internet extraordinariamente bem-sucedidas. O Google demonstrou como software e distribuição online poderiam alcançar públicos enormes com relativamente pouco esforço incremental. Fundadores e investidores naturalmente começaram a procurar modelos de crescimento igualmente repetíveis.
Essa ambição gradualmente se tornou uma limitação. Empreendedores sentiam pressão para apresentar uma solução escalável antes de provar que alguém precisava dela. Podiam passar meses projetando sistemas automatizados para uma demanda hipotética, mantendo-se distantes dos clientes reais.
O ensaio de Paul Graham contestou essa sequência. Como explicam os participantes do painel, a maioria das startups jovens não é ameaçada por demanda excessiva ou por infraestrutura em colapso. Seu risco imediato é muito mais simples: talvez nunca atraiam usuários suficientes ou construam algo que as pessoas não valorizam.
A prioridade prática, portanto, é resolver o problema diretamente, mesmo que o primeiro método exija muito trabalho. A escalabilidade importa no fim das contas, mas somente depois que a empresa encontra algo que vale a pena escalar.
Chegar do Zero ao Um Vem Primeiro
A discussão apresenta o progresso de uma startup como uma série de limitações imediatas. No início, o desafio não é atender o milionésimo cliente de maneira eficiente. É conquistar o primeiro cliente, entregar o primeiro resultado bem-sucedido e aprender por que essa pessoa escolheu o produto.
Isso muda a forma como os fundadores devem avaliar o trabalho inicial. Uma tarefa que parece ineficiente em uma empresa madura pode ser totalmente racional quando responde rapidamente a uma questão crítica. Integrar pessoalmente um cliente, montar manualmente um serviço ou improvisar um fluxo de trabalho interno pode revelar mais do que semanas construindo infraestrutura de forma isolada.
Os participantes usam o Airbnb como exemplo marcante. Seus fundadores precisavam de anúncios melhores, então ajudaram anfitriões a produzir fotografias de maior qualidade. Viajar até as propriedades e melhorar os anúncios individualmente jamais poderia ser o modelo operacional permanente. Ainda assim, isso resolveu o problema urgente da empresa: tornar o marketplace mais atraente e gerar atividade suficiente para que o crescimento começasse.
A lição não é que todo fundador deva reproduzir a tática do Airbnb. É que fundadores devem identificar diretamente o obstáculo à sua frente e estar dispostos a resolvê-lo sem esperar por um sistema elegante.
A Fleek Aprendeu o Marketplace Antes de Construí-lo
A Fleek oferece uma ilustração especialmente vívida do aprendizado por meio de operações manuais. A empresa começou sem um site concluído, sem um estoque de roupas e sem uma infraestrutura sofisticada de marketplace. Em vez disso, seus fundadores foram até atacadistas de Londres, desenvolveram relacionamentos e conectaram diretamente a oferta às lojas.
O painel descreve como a equipe chegou a transportar roupas entre atacadistas e varejistas. Sob uma perspectiva convencional de eficiência, fundadores carregando mercadorias por conta própria parece uma falha de processo. Sob a perspectiva do aprendizado, no entanto, isso os colocou dentro da transação.
Ao participar do trabalho, a Fleek pôde observar o que os varejistas queriam, como os atacadistas se comportavam, quais preços funcionavam e como a demanda respondia às mudanças. Não eram respostas abstratas de pesquisas. Eram insights obtidos enquanto ajudavam compradores e vendedores reais a concluir compras reais.
Após cerca de quatro meses operando manualmente, os fundadores tinham conhecimento suficiente para levar a atividade ao ambiente online. O marketplace foi informado por comportamentos que a equipe já havia observado, e não por suposições sobre como o mercado deveria funcionar.
A Integração Prática Cria Produtos Melhores
Os participantes apontam Stripe e Algolia como outros exemplos de fundadores fechando a lacuna entre desenvolvimento de produto e a realidade dos clientes. Os fundadores da Stripe ajudavam os primeiros usuários a instalar seu software de pagamentos, em vez de simplesmente enviar documentação e esperar. A Algolia também ajudou o Product Hunt a implementar a busca.
A implementação direta realiza mais do que ativar uma nova conta. Ela expõe etapas confusas de configuração, dependências técnicas ocultas e diferenças entre o que os clientes dizem precisar e aquilo com que realmente têm dificuldade na prática.
Ela também pode mudar o relacionamento. Um cliente que trabalhou lado a lado com um fundador tem maior probabilidade de compartilhar feedback sincero do que alguém que envia um chamado de suporte para uma empresa desconhecida. Essa confiança dá à startup acesso a insights mais precisos sobre o produto.
Os participantes do painel descrevem essa atenção pessoal — o “FaceTime” do fundador — como uma vantagem que empresas estabelecidas muitas vezes não conseguem igualar. Um grande concorrente pode ter mais recursos, mas geralmente não consegue ter seus fundadores pessoalmente comprometidos com o sucesso de cada pequeno cliente. Para uma startup com um produto incompleto e credibilidade limitada, um cuidado visível pode se tornar parte da proposta de valor.
Otimize o Trabalho Inicial para Aprender
O argumento central da discussão é que os fundadores devem otimizar a fase inicial para o aprendizado, e não para a elegância operacional. A entrega manual ajuda a estabelecer se o resultado prometido é realmente valioso antes que a equipe codifique esse processo em software.
Esse princípio pode ser traduzido em uma sequência simples:
Identifique a incerteza mais importante do negócio.
Crie a maneira mais rápida e confiável de testá-la com clientes reais.
Execute o trabalho manualmente quando a automação atrasaria a resposta.
Registre o que cria valor repetidamente ou causa atrito.
Construa sistemas somente depois que o padrão se tornar claro.
Isso não significa tratar todo processo improvisado como prova de um negócio viável. O trabalho manual é útil quando gera evidências. Os fundadores ainda precisam determinar se a demanda se repete, se os clientes pagarão e se o serviço subjacente poderá, no futuro, sustentar um modelo de negócio atraente.
O que devem evitar é confundir refinamento técnico com validação. Uma plataforma belamente projetada não pode compensar um produto indesejado.
Instacart e DoorDash Testaram a Demanda com Ferramentas Improvisadas
A história da Instacart mostra como fundadores podem testar um marketplace antes de obter todas as parcerias que uma versão madura exigiria. Como relatado no vídeo, a empresa foi lançada sem relacionamentos formais com supermercados. A equipe comprava itens no Trader Joe’s, fotografava-os e os listava online para verificar se os clientes pediriam compras de supermercado para entrega.
Essa abordagem contornou um ciclo potencialmente longo de negociações de parceria. Em vez de pedir aos varejistas que apoiassem um conceito não comprovado, os fundadores primeiro reuniram evidências de que os consumidores queriam o serviço.
A DoorDash seguiu uma rota igualmente pragmática. Os participantes descrevem seu produto inicial como algo montado em um único dia com ferramentas comuns, incluindo Google Drive e Find My Friends. O objetivo não era criar imediatamente uma plataforma logística duradoura. Era descobrir se os consumidores locais pediriam entregas de restaurantes e se os fundadores conseguiriam atender a esses pedidos.
Esses experimentos aproveitaram uma vantagem real das startups: equipes pequenas podem coordenar temporariamente o trabalho de formas que seriam impraticáveis para grandes organizações. Elas têm menos processos a proteger, menos infraestrutura a integrar e mais liberdade para mudar de direção após cada resultado.
Sistemas Imperfeitos Tornam a Adaptação Mais Rápida
Fazer as coisas manualmente permite que uma equipe revise a experiência sem reconstruir um produto inteiro. Se os clientes não gostam de uma etapa, os fundadores podem mudá-la no pedido seguinte. Se uma suposição se mostra falsa, podem abandoná-la antes que ela fique incorporada a meses de trabalho de engenharia.
Os participantes também argumentam que os fundadores não devem ter medo excessivo de erros operacionais iniciais. Problemas criados pelo aumento da demanda geralmente geram fortes incentivos para encontrar soluções rapidamente. Quando uma startup finalmente tem mais usuários do que seu processo improvisado consegue atender, a necessidade de automação se torna concreta, urgente e mais fácil de definir.
É por isso que startups raramente fracassam porque atraíram clientes demais e não conseguiram escalar. Problemas de capacidade são dolorosos, mas vêm acompanhados de evidências de demanda. A falta de usuários é muito mais perigosa porque não oferece nem receita nem uma razão clara para continuar construindo.
A implicação para a engenharia é importante: adiar a infraestrutura pode ser uma forma de velocidade, e não negligência, desde que os atalhos sejam compreendidos e não criem riscos inaceitáveis para os clientes.
Sabendo Quando Construir para Escalar
O trabalho não escalável é um método de descoberta, não uma filosofia permanente. Quando uma startup entende o trabalho recorrente, vê demanda sustentada e encontra gargalos manuais, ela precisa começar a transformar o que aprendeu em sistemas repetíveis.
O painel observa que mentores e investidores experientes podem ajudar os fundadores a reconhecer essa transição. Escalar cedo demais desperdiça recursos em suposições não verificadas. Escalar tarde demais pode prejudicar a qualidade do serviço, esgotar a equipe e impedir a empresa de capturar a demanda.
Um sinal útil é a repetição. Se os fundadores continuam resolvendo o mesmo problema aproximadamente da mesma forma, o software talvez possa padronizar o processo. Outro é o custo de oportunidade: quando a entrega manual consome tempo que poderia gerar aprendizado ou crescimento mais valioso, a automação se torna cada vez mais atraente.
O objetivo não é eliminar o envolvimento humano por si só. É automatizar as partes que agora são compreendidas, preservando o contato próximo onde os clientes ainda estão ensinando algo importante à empresa.
Consultoria Pode Ser uma Ponte, mas Não o Destino
Os participantes também abordam a fronteira entre uma startup de software e uma consultoria. Uma empresa jovem pode obter receita fornecendo serviços práticos a negócios, e seu primeiro produto pode simplesmente tornar esse serviço mais rápido ou mais confiável.
Esse pode ser um ponto de partida produtivo. O trabalho de consultoria expõe os fundadores a ambientes operacionais reais e lhes dá conhecimento detalhado sobre os problemas dos clientes. Também pode financiar o desenvolvimento inicial.
No entanto, o painel alerta que a receita de serviços, por si só, não cria uma empresa de software de alto crescimento. O trabalho personalizado se expande principalmente com a adição de pessoas, enquanto um produto escalável pode atender muito mais clientes sem crescimento proporcional do quadro de funcionários. Metas ambiciosas de crescimento ajudam a impor essa distinção: se espera-se que o negócio cresça em uma ordem de grandeza, os fundadores precisam eventualmente transformar conhecimento recorrente em produto, em vez de vender indefinidamente trabalho sob medida.
A Vantagem Duradoura do Esforço dos Fundadores
A mensagem final do vídeo é que a disposição para realizar tarefas desconfortáveis, manuais ou aparentemente pequenas é uma das maiores vantagens de uma startup sobre concorrentes estabelecidos. Esse trabalho aproxima os fundadores dos clientes, acelera experimentos e cria oportunidades para oferecer um serviço excepcionalmente atencioso.
O princípio mais profundo não é uma celebração da ineficiência. É um sequenciamento disciplinado. Primeiro, aprenda o que as pessoas precisam. Depois, prove que elas agirão com base nessa necessidade. Entregue o resultado por qualquer método responsável disponível, estude o padrão recorrente e só então invista em torná-lo repetível.
A escalabilidade se torna valiosa quando a demanda a justifica. Antes desse ponto, o sistema mais eficaz do fundador pode ser simplesmente curiosidade, urgência e disposição para fazer o trabalho pessoalmente.
