Por dentro do colapso: seis lições aprendidas com o fim de uma startup de robótica

Os robôs humanóides de código aberto K-Bot. | Crédito: K-Scale Labs

Nota do editor: Rui Xu é o ex-diretor de operações da K-Scale Labs, uma startup sediada em São Francisco que tentou construir robôs humanóides de baixo custo. A empresa fechou no final de 2025 e recentemente tornou sua propriedade intelectual de código aberto. Xu publicou este artigo pela primeira vez no LinkedIn. Ele foi reimpresso com sua permissão.

Durante um ano, atuei como diretor de operações em uma startup de robótica apoiada pela Y Combinator com o ambicioso objetivo de criar robôs humanóides acessíveis. Aos quarenta anos, trouxe 15 anos de experiência em hardware, adquirida em lançamentos de produtos na Intel, Xiaomi, Lenovo, Amazon e ByteDance, para liderar a cadeia de suprimentos e as operações de produtos.

No final das contas, a empresa não teve sucesso. Não conseguimos garantir nosso financiamento da Série A e, no final de 2025, tudo acabou.

Já compartilhei os destaques: as hackathons, a energia do estilo garagem, o momento em que nosso robô deu os primeiros passos. Agora, quero detalhar as lições reais que aprendemos. Algumas são armadilhas comuns ao setor; outras foram erros que cometemos ativamente.

1. O chauvinismo dos grandes modelos vai prejudicar alguém

Uma crença generalizada sugere que os modelos de IA se tornaram tão avançados que o hardware pode ser simplista. Sensores? O modelo interpretará tudo a partir da visão. Limites de segurança? A rede de políticas aprenderá a evitá-los.

Chamo isso de “chauvinismo dos grandes modelos”. Isso influenciou sutilmente inúmeras decisões em nossa startup. Para ser claro, não foi um descuido de um indivíduo — a maioria de nós acreditava nisso até certo ponto. As capacidades da IA eram genuinamente impressionantes, fazendo com que fosse fácil para esse entusiasmo ofuscar os princípios fundamentais do hardware.

Um debate que ainda me assombra diz respeito à adição de batentes finais às articulações do robô. Batentes finais — interruptores de limite mecânicos — são barreiras físicas básicas que impedem que uma articulação se autodestrua. É a redundância de segurança mais fundamental.

O contra-argumento era que a política de IA deveria aprender os limites da articulação naturalmente e que os batentes finais adicionavam custo e peso desnecessários.

Qualquer pessoa com experiência em hardware sabe que esse raciocínio é falho. Os batentes existem porque o software pode falhar e falhará. Os modelos apresentam falhas. As políticas encontram casos extremos imprevistos. Quando um modelo de linguagem tem alucinações, você obtém uma resposta sem sentido. Quando um atuador, devido a uma única inferência defeituosa, excede seu limite mecânico em torque total, você obtém uma máquina quebrada — ou pior, um ferimento.

O modelo pode estar correto 99,99% das vezes. O batente final é para os 0,01%. No mundo físico, esses 0,01% são a única estatística que realmente importa. Mesmo a Tesla, com todos os seus objetivos de autonomia, ainda instala freios em seus carros.

2. Analogias simplificadas demais são para arrecadar fundos, não para construir

Todo pitch deck de robótica tem um: “Estamos fazendo pelos robôs o que a Tesla fez pelos veículos elétricos” ou “Este é o momento iPhone para a IA incorporada”. Nossa referência era a analogia do hoverboard. A narrativa era que os robôs humanóides seguiriam a mesma curva de custo das scooters com autoequilíbrio: de novidade cara, passando pela produção em massa em Shenzhen, até se tornarem hardware barato e onipresente.

O motor de um hoverboard só precisa girar. Os atuadores de um robô humanóide, no entanto, devem ser extraordinariamente precisos, poderosamente dinâmicos, duráveis e consistentes de unidade para unidade. Um único atuador ligeiramente fora da especificação pode fazer com que o robô ande incorretamente ou caia. Analogias com hoverboards, smartphones ou qualquer outro dispositivo de consumo não fornecem orientações úteis para a construção de um humanóide.

No entanto, “será como um hoverboard” é uma história que os investidores de capital de risco entendem. Ela promete redução inevitável de custos, proeza da manufatura chinesa e escala de bilhões de unidades. Cada hora gasta debatendo essas analogias foi uma hora não gasta resolvendo desafios técnicos reais.

As analogias são algoritmos de compressão. Elas simplificam a complexidade descartando informações. Isso é bom para uma apresentação de vendas. Nas decisões de engenharia, as informações descartadas são frequentemente o que leva ao fracasso.

3. A cadeia de suprimentos de hardware não é uma tarefa simples

Alguns fundadores orientados para software veem a gestão da cadeia de suprimentos como uma tarefa simples: contratar alguém que fale chinês, indicar uma fábrica e considerar o trabalho feito. Esse equívoco é uma armadilha comum para startups de hardware.

Quando entrei, não havia infraestrutura de cadeia de suprimentos — nenhum relacionamento com fabricantes, nenhuma condição de pagamento, nenhum processo de controle de qualidade, nenhum canal de logística. Construí-la envolveu coordenar a montagem, os componentes, os atuadores e vários fabricantes contratados chineses para a fabricação. Cada um exigia negociações separadas sobre preços, padrões de qualidade, quantidades mínimas de pedido e cronogramas de produção, tudo em diferentes moedas, fusos horários e culturas empresariais com premissas fundamentalmente diferentes sobre a realização de negócios.

Isso não é apenas “conversar com fornecedores”. A fabricação não é um serviço que você compra; é uma capacidade essencial que você deve construir. Seu relacionamento com o fabricante contratado determina se os atuadores chegam dentro da tolerância ou se estão 2 mm fora dela, e se o custo unitário é de US$ 800 ou US$ 2.400. Se as operações de hardware de uma empresa podem ser resumidas em uma frase, ela não tem uma estratégia de hardware — ela tem uma esperança.

4. Hardware “commodity” não existe na robótica

Uma ideia particularmente perigosa que circula é que o hardware dos robôs se tornará uma “commodity”, montado a partir de peças prontas por fabricantes chineses, muito parecido com os smartphones, com o valor real residindo exclusivamente na camada de software de IA.

Essa não é a realidade atual, nem mesmo perto disso. Não existe uma lista padrão de materiais para um robô humanóide. Nenhum atuador pronto para uso funciona simplesmente para locomoção bípede. Todas as equipes que constroem robôs com pernas hoje estão projetando hardware personalizado.

Quando uma empresa acredita na narrativa de que “o hardware é uma mercadoria”, ocorrem danos reais. As equipes que constroem o produto físico muitas vezes recebem menos voz e reconhecimento do que suas contribuições merecem. O poder organizacional muda para qualquer função considerada estrategicamente “defensável”, independentemente de quem está fazendo o trabalho mais difícil.

Observei um padrão recorrente que chamo de “especialização de Schrödinger”. Quando surge um problema de hardware, as mesmas pessoas de repente “não são especialistas em hardware” e afirmam não ter ideia do que fazer. No entanto, quando a equipe de engenharia afirma que um redesenho levará quatro meses, elas insistem que isso deve ser feito em quatro semanas. Não dá para ter as duas coisas, e os engenheiros que fazem o trabalho real percebem isso claramente.

Nossos engenheiros construíram um robô que andava. Essa foi a façanha de engenharia mais difícil que a empresa alcançou.

5. Decisões ruins de P&D matam mais rápido do que azar em uma corrida

O campo da robótica é uma corrida. O capital está disponível, os talentos estão chegando e o mercado está observando. Mas uma corrida recompensa a velocidade, e velocidade não é apenas esforço — é o resultado de tomar decisões corretas rapidamente.

O maior erro que testemunhei foi ficar preso na locomoção. Meses se passaram e o robô ainda não conseguia andar corretamente. Enquanto isso, a janela de captação de recursos se fechou e os concorrentes lançaram demonstrações impressionantes. Isso não foi apenas uma falha da liderança; toda a equipe, incluindo eu mesmo, subestimou a complexidade e o prazo do problema. Nosso GitHub estava cheio de repositórios, o que, visto de fora, parecia progresso. Por dentro, era movimento sem convergência. Repositórios não são entregues. Demonstrações são entregues. Produtos são entregues.

A questão mais profunda era a qualidade das decisões. Decisões impulsivas podem ser tão fatais quanto decisões lentas. Comprometer-se totalmente com a direção errada não economiza tempo; dobra o custo, porque você precisa desfazer o trabalho mais tarde.

A velocidade de P&D não é medida por repositórios, commits ou horas registradas. É medida pela rapidez com que você converge para uma solução que realmente funciona.

6. Quanto mais você se apressa, mais você fica para trás

Os prazos do nosso projeto se tornaram uma piada interna. O robô sempre iria andar “na próxima semana”. Todas as semanas.

Quando essa cultura se instala, as pessoas começam a cortar custos para cumprir prazos impossíveis. Os engenheiros usam ferramentas de codificação de IA sem a revisão adequada. Os sensores são integrados sem calibração completa. Então, a demonstração falha — novamente — e o cronograma é redefinido para “na próxima semana”.

Isso incorpora o provérbio chinês “欲速则不达” (yù sù zé bù dá): literalmente, “desejar velocidade, não chegar”. Quando prazos irrealistas se tornam a norma, a equipe não trabalha mais rápido. Ela simplesmente pula as etapas essenciais que fazem as coisas funcionarem. Cada etapa pulada acaba resultando em uma falha que custa mais tempo do que o atalho economizou.

O dano vai além da engenharia. Quando você faz promessas ao seu fabricante contratado com base em cronogramas fantasiosos, você queima esse relacionamento crítico. Um fabricante precisa de previsões realistas para planejar sua produção. Uma mentalidade caótica de “agir rápido e quebrar coisas” pode funcionar em software, mas falha completamente quando uma fábrica está alocando linhas de produção com base em compromissos que você não pode cumprir.

Uma nota pessoal

Eu poderia ter sido um COO melhor. Eu deveria ter sido mais assertivo desde o início sobre as questões organizacionais, quando elas ainda eram corrigíveis. Eu deveria ter pressionado mais por prazos realistas, em vez de deixá-los passar. Essa responsabilidade é minha. Mas aprendi onde estão esses limites e levarei esse conhecimento adiante.

Estive presente durante toda a jornada, desde o primeiro hackathon até o e-mail final para um fornecedor.

Para qualquer jovem engenheiro em uma startup: confie em seus instintos em relação à física. Se os cálculos indicarem que uma junta irá falhar, documente isso. Apresente seu caso formalmente. Não deixe que a pressão para agir rapidamente o intimide a ignorar o que você sabe ser verdade. Sua reputação profissional é construída com base no que você realmente entrega, não no que promete.

Se essas seis lições ajudarem alguém — um fundador de hardware, um profissional da cadeia de suprimentos ou um pai de quarenta anos pensando em seguir carreira em uma startup —, então valeu a pena escrever isso.

Ainda acredito na IA incorporada. Simplesmente acredito que ela merece um hardware projetado com a mesma seriedade que o software que a controla.

Sobre o autor

Rui Xu é um veterano da indústria de hardware baseado no Vale do Silício. Anteriormente, atuou como diretor de operações da K-Scale Labs, uma startup de robótica apoiada pela Y Combinator focada em robôs humanóides acessíveis. Antes disso, ele passou 18 anos comercializando produtos de hardware de consumo na Intel, Xiaomi, Lenovo, Amazon e ByteDance, incluindo o Xiaomi Mi Box, Lenovo Smart Display e Amazon Fire TV. Ele escreve sobre robótica, hardware e as realidades da construção de produtos físicos em ruixu.us.