Inside the Collapse: Six Lessons from a Robotics Startup's Demise

The K-Bot open-source humanoid robots. | Credit: K-Scale Labs

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.

For a year, I served as COO at a Y Combinator-backed robotics startup with the ambitious goal of creating affordable humanoid robots. At forty, I brought 15 years of hardware experience from product launches at Intel, Xiaomi, Lenovo, Amazon, and ByteDance to lead supply chain and product operations.

Ultimately, the company did not succeed. We failed to secure our Series A funding, and by the end of 2025, it was over.

I've previously shared the highlights: the hackathons, the garage-style energy, the moment our robot first walked. Now, I want to detail the real lessons learned. Some are industry-wide pitfalls; others were mistakes we actively made.

1. Large Model Chauvinism Will Get Someone Hurt

A pervasive belief suggests that AI models have become so advanced that hardware can afford to be simplistic. Sensors? The model will interpret everything from vision. Safety limits? The policy network will learn to avoid them.

I term this "Large Model Chauvinism." It subtly influenced countless decisions at our startup. To be clear, it wasn't one individual's oversight—most of us subscribed to it to some extent. The AI's capabilities were genuinely awe-inspiring, making it easy for that excitement to overshadow fundamental hardware principles.

One debate that still haunts me concerned adding end stops to the robot's joints. End stops—mechanical limit switches—are basic physical barriers that prevent a joint from self-destructing. It's the most fundamental safety redundancy.

The counter-argument was that the AI policy should learn the joint's limits naturally, and that end stops added unnecessary cost and weight.

Anyone with hardware experience knows this reasoning is flawed. End stops exist because software can and will fail. Models glitch. Policies encounter unforeseen edge cases. When a language model hallucinates, you get a nonsensical answer. When an actuator, due to a single faulty inference, exceeds its mechanical limit at full torque, you get a broken machine—or worse, an injury.

The model might be correct 99.99% of the time. The end stop is for the 0.01%. In the physical world, that 0.01% is the only statistic that truly matters. Even Tesla, with all its autonomy goals, still installs brakes on its cars.

2. Over-Simplified Analogies Are for Fundraising, Not Building

Every robotics pitch deck has one: "We're doing for robots what Tesla did for EVs," or "This is the iPhone moment for embodied AI." Our go-to was the hoverboard analogy. The narrative was that humanoid robots would follow the same cost curve as self-balancing scooters: from expensive novelty, through mass production in Shenzhen, to becoming cheap, ubiquitous hardware.

A hoverboard motor only needs to spin. A humanoid robot's actuators, however, must be extraordinarily precise, powerfully dynamic, durable, and consistent from unit to unit. A single actuator slightly out of spec can cause the robot to walk incorrectly or fall. Analogies to hoverboards, smartphones, or any other consumer device provide no useful guidance for building a humanoid.

Yet, "it'll be like a hoverboard" is a story venture capitalists understand. It promises inevitable cost reduction, Chinese manufacturing prowess, and billion-unit scale. Every hour spent debating these analogies was an hour not spent solving actual technical challenges.

Analogies are compression algorithms. They simplify complexity by discarding information. That's fine for a pitch deck. In engineering decisions, the discarded information is often what leads to failure.

3. Hardware Supply Chain Is Not a Simple Task

Some software-oriented founders view supply chain management as a mere task: hire someone who speaks Chinese, point them at a factory, and consider it done. This misconception is a common pitfall for hardware startups.

When I joined, there was no supply chain infrastructure—no manufacturer relationships, no payment terms, no quality control process, no logistics pipeline. Building it involved coordinating assembly, components, actuators, and multiple Chinese contract manufacturers for fabrication. Each required separate negotiations on pricing, quality standards, minimum order quantities, and production schedules, all across different currencies, time zones, and business cultures with fundamentally different assumptions about deal-making.

This is not merely "talking to suppliers." Manufacturing is not a service you purchase; it's a core capability you must build. Your relationship with your contract manufacturer determines whether actuators arrive within tolerance or are 2mm off, and whether your unit cost is $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. "Commodity" Hardware Does Not Exist in Robotics

A particularly dangerous idea circulating is that robot hardware will become a "commodity," assembled from off-the-shelf parts by Chinese manufacturers, much like smartphones, with the real value residing solely in the AI software layer.

This is not the current reality, not even close. There is no standard bill of materials for a humanoid robot. No off-the-shelf actuators simply work for bipedal locomotion. Every team building a legged robot today is designing custom hardware.

When a company buys into the "hardware is a commodity" narrative, real damage occurs. The teams building the physical product often receive less voice and recognition than their contributions warrant. Organizational power shifts to whichever function is deemed strategically "defensible," regardless of who is doing the most difficult work.

I observed a recurring pattern I call "Schrödinger's Expertise." When a hardware issue arises, the same people are suddenly "not hardware experts" and claim to have no idea. Yet, when the engineering team states a redesign will take four months, they insist it should be done in four weeks. You can't have it both ways, and the engineers doing the actual work see straight through this.

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

5. Poor R&D Decisions Kill Faster Than Bad Luck in a Race

The robotics field is a race. Capital is available, talent is pouring in, and the market is watching. But a race rewards speed, and speed is not just effort—it's the result of making correct decisions rapidly.

The single biggest mistake I witnessed was becoming stuck on locomotion. Months were consumed while the robot still couldn't walk properly. Meanwhile, the fundraising window closed, and competitors released impressive demos. This wasn't solely a leadership failure; the entire team, myself included, underestimated the problem's complexity and timeline. Our GitHub was full of repositories, which from the outside looked like progress. From the inside, it was motion without convergence. Repositories don't ship. Demos ship. Products ship.

The deeper issue was decision quality. Impulsive decisions can be just as fatal as slow ones. Committing fully to the wrong direction doesn't save time; it doubles the cost because you must later undo the work.

R&D velocity isn't measured by repositories, commits, or hours logged. It's measured by how quickly you converge on a solution that actually works.

6. The More You Rush, the Further You Fall Behind

Our project timelines became an internal joke. The robot was always going to walk "next week." Every single week.

When that culture takes hold, people start cutting corners to meet impossible deadlines. Engineers use AI coding tools without proper review. Sensors are integrated without full calibration. Then the demo fails—again—and the timeline resets to "next week."

This embodies the Chinese proverb "欲速则不达" (yù sù zé bù dá): literally, "desire speed, fail to arrive." When unrealistic deadlines become the norm, the team doesn't actually move faster. They simply skip the essential steps that make things work. Every skipped step eventually results in a failure that costs more time than the shortcut ever saved.

The damage extends beyond engineering. When you make promises to your contract manufacturer based on fantastical timelines, you burn that critical relationship. A manufacturer needs realistic forecasts to plan its production. A chaotic "move fast and break things" mindset might work in software, but it fails utterly when a factory is allocating production lines based on commitments you cannot keep.

A Personal Note

I could have been a better COO. I should have been more assertive earlier about organizational issues when they were still fixable. I should have pushed harder for realistic timelines instead of letting them slide. That responsibility is mine. But I've learned where those lines are, and I'll carry that knowledge forward.

I was there for the entire journey, from the first hackathon to the final email to a supplier.

To any young engineer at a startup: Trust your instincts regarding physics. If the calculations indicate a joint will fail, document it. Make your case formally. Don't let the pressure to move fast bully you into ignoring what you know is true. Your professional reputation is built on what you actually deliver, not what you promise.

If these six lessons help someone—a hardware founder, a supply chain professional, or a forty-year-old parent contemplating a startup career—then writing this was worthwhile.

I still believe in embodied AI. I simply believe it deserves hardware engineered with the same seriousness as the software that controls it.

About the Author

Rui Xu is a hardware industry veteran based in Silicon Valley. He previously served as Chief Operating Officer of K-Scale Labs, a Y Combinator-backed robotics startup focused on affordable humanoid robots. Prior to that, he spent 18 years shipping consumer hardware products at Intel, Xiaomi, Lenovo, Amazon, and ByteDance, including the Xiaomi Mi Box, Lenovo Smart Display, and Amazon Fire TV. He writes about robotics, hardware, and the realities of building physical products at ruixu.us.