6 lessons I learned watching a robotics startup die from the inside

Editor’s Note: Rui Xu is the former chief operating officer of K-Scale Labs, a San Francisco-based startup that tried to build low-cost humanoid robots. The company shut down in late 2025 and recently open-sourced its intellectual property. Xu first published this article on LinkedIn. It was reprinted with his permission.

I spent a year as COO of a YC-backed robotics startup trying to build affordable humanoid robots. I was forty, had 15 years of hardware experience shipping products at Intel, Xiaomi, Lenovo, Amazon and ByteDance, and joined to run supply chain and product operations.

The company didn’t make it. We never closed our Series A. By late 2025, it was over.

I’ve written about the good parts before. The hackathons, the garage energy, the first time the robot walked. This time I want to write down what I actually learned. Some of these are industry-wide traps. Some we walked into ourselves.

1. Large Model Chauvinism Will Get Someone Hurt

There’s this belief going around that AI models are getting so good that hardware can afford to be dumb. Sensors? The model will figure it out from vision. Safety limits? The policy will learn to avoid them.

I call this Large Model Chauvinism. At our startup, it shaped decisions constantly. And to be fair, it wasn’t one person’s blind spot — most of us bought into it to some degree. The AI was genuinely impressive, and it was easy to let that excitement paper over hardware fundamentals.

One example that still bugs me. We spent a genuinely long time debating whether to add end stops to the robot’s joints. End stops. Mechanical limit switches. A piece of metal that physically prevents a joint from destroying itself. Most basic safety redundancy there is.

The argument against: the AI policy should learn the joint limits. End stops are extra cost, extra weight.

Anyone who’s done hardware knows why this doesn’t hold up. End stops exist because software fails. Models glitch. Policies hit edge cases nobody anticipated. When a language model hallucinates, you get a wrong answer. When an actuator blows past its joint limit at full torque because the policy had one bad inference step, you get a broken machine. Or a broken person.

The model might be right 99.99% of the time. The end stop is for the 0.01%. In the physical world, 0.01% is the only number that matters. Even Tesla, with all its autonomy ambitions, still puts brakes on the car.

---

---

2. Stop using over-simplified analogies. They’re for fundraising, not for building.

Every robotics pitch deck has one. “We’re doing for robots what Tesla did for EVs.” “This is the iPhone moment for embodied AI.” At our company, the favorite was the hoverboard (平衡车). Humanoid robots would follow the same cost curve as self-balancing scooters: expensive novelty → Shenzhen mass production → commodity hardware → everywhere.

A hoverboard motor just needs to spin. That’s it. A humanoid robot’s actuators need to be extraordinarily precise, explosively powerful, resistant to wear, and consistent unit to unit. One actuator slightly out of spec and the robot walks wrong, or falls. Hoverboards, smartphones, whatever analogy you pick, none of them tell you anything useful about building a humanoid.

But “it’ll be like a hoverboard” is a story VCs get. Inevitable cost reduction, China manufacturing magic, billion-unit scale. Every hour spent on analogy debates was an hour not spent on the actual technical problems.

Analogies are compression algorithms. They make complex things simple by throwing away information. In a pitch deck, fine. In an engineering decision, the thrown-away information is usually the part that kills you.

3. Hardware supply chain is not a task

A few software founders think supply chain is a task. Find someone who speaks Chinese, point them at a factory, check the box. This is one of the most common ways hardware startups get into trouble.

When I joined, there was nothing. No manufacturer relationships, no payment terms, no QC process, no logistics pipeline. Building it meant assembly, components, actuators, multiple Chinese CMs for fabrication. Each one meant separate negotiations on pricing, quality standards, MOQs, production scheduling, across currencies, time zones, and business cultures that operate on completely different assumptions about how deals work.

That is not “talking to suppliers.” Manufacturing is not a service you buy. It’s a capability you build. Your relationship with your CM determines whether actuators come in within tolerance or 2mm off. Whether unit cost lands at $800 or $2,400. If a company’s hardware operations can be summarized in one sentence, it doesn’t have a hardware strategy. It has a hope.

4. There is no such thing as “commodity” in robotics hardware

One of the most dangerous ideas going around: robot hardware will become “commodity,” assembled from off-the-shelf parts by Chinese manufacturers just like phones, with the real value sitting in the AI layer.

Not yet. Not even close. There’s no standard BOM for a humanoid. No off-the-shelf actuators that just work for walking. Every team building a legged robot right now is designing custom hardware.

But when a company buys into the “hardware is commodity” story, the damage is real. The people building the physical product end up with less voice and less recognition than what they actually contributed. Power shifts to whichever function gets the “defensible” label, no matter who’s doing the hardest work.

There’s a pattern I saw a lot. I call it Schrödinger’s expertise. When something goes wrong on the hardware side, suddenly they’re not a hardware person, they have no idea. When the engineering team says a redesign takes four months, suddenly it should be done in four weeks. You can’t have it both ways, and the engineers who are actually doing the work can see right through it.

Our engineers built a robot that walked. That was the hardest engineering the company did.

5. In a race, bad R&D decisions kill faster than bad luck

Everyone in robotics is racing. Capital is there, talent is flooding in, the market is paying attention. But a race rewards speed, and speed is not effort. Speed comes from making the right calls fast.

The single biggest mistake I saw was getting stuck on locomotion. Months burned, the robot still wasn’t walking right, and meanwhile the fundraising window closed and competitors shipped demos. This wasn’t just a leadership call — the whole team, myself included, underestimated how hard the problem was and how long it would take. The GitHub was full of repos. From the outside it looked like velocity. From the inside it was motion without convergence. Repos don’t ship. Demos ship. Products ship.

The deeper issue was decision quality. Impulsive calls kill just as fast as slow ones. Committing hard to the wrong direction doesn’t save time, it costs double, because you still have to undo it later.

R&D velocity isn’t repos or commits or hours logged. It’s how fast you converge on something that actually works.

6. 欲速则不达 — the more you rush, the further you fall behind

Our timelines were a running joke. It was always the robot walks next week. Every week.

When that’s the culture, people start cutting corners to hit impossible dates. Engineers write code with AI tools without reviewing it properly. Sensors go onto the product without calibration. And then the demo fails, again, and the timeline resets to next week.

This is what the Chinese call 欲速则不达. Literally: desire speed, fail to arrive. When unrealistic deadlines become the norm, the team doesn’t actually move faster. They just skip the steps that make things work. And every skipped step comes back as a failure that costs more time than the shortcut saved.

The damage goes beyond engineering. When you make promises to your contract manufacturer based on fantasy timelines, you burn the relationship. A CM needs realistic expectations to plan their own production. A chaotic “move fast, break things” mindset might work in software. It does not work when your manufacturer is allocating factory floor time based on commitments you can’t keep.

A personal note

I could have been a better COO. Should have been firmer earlier about the organizational problems, back when they were fixable. Should have pushed harder on realistic timelines instead of letting them slide. That’s on me. But I learned where those lines are now, and that’s something I take into whatever comes next.

But I was there for the whole thing. First hackathon to last supplier email.

If you’re a young engineer at a startup: trust your instincts on physics. If the math says the joint will break, write it down. Make the case formally. Don’t let the pressure to move fast bully you into ignoring what you know to be true. Your reputation is built on what you ship, not what you promised.

If these six lessons help someone, a hardware founder, a supply chain person, a forty-year-old parent wondering whether to join a startup, then this was worth writing.

I still believe in embodied AI. I just believe it deserves hardware that’s as seriously engineered as the software controlling it.

About the Author

Rui Xu is a hardware veteran based in Silicon Valley. He previously served as COO of K-Scale Labs, a YC-backed robotics startup building affordable humanoid robots. Before that, he spent 18 years shipping consumer hardware at Intel, Xiaomi, Lenovo, Amazon, and ByteDance, including products like the Xiaomi Mi Box, Lenovo Smart Display, and Amazon Fire TV. He writes about robotics, hardware, and the reality of building physical products at ruixu.us.

The post 6 lessons I learned watching a robotics startup die from the inside appeared first on The Robot Report.