The Okay-Bot open-source humanoid robots. | Credit score: Okay-Scale Labs
Editor’s Notice: Rui Xu is the previous chief working officer of Okay-Scale Labs, a San Francisco-based startup that attempted to construct low-cost humanoid robots. The corporate shut down in late 2025 and not too long ago open-sourced its mental property. Xu first revealed this text on LinkedIn. It was reprinted together with his permission.
I spent a yr as COO of a YC-backed robotics startup attempting to construct reasonably priced humanoid robots. I used to be forty, had 15 years of {hardware} expertise transport merchandise at Intel, Xiaomi, Lenovo, Amazon and ByteDance, and joined to run provide chain and product operations.
The corporate didn’t make it. We by no means closed our Sequence A. By late 2025, it was over.
I’ve written in regards to the good elements earlier than. The hackathons, the storage power, the primary time the robotic walked. This time I need to write down what I really realized. A few of these are industry-wide traps. Some we walked into ourselves.
1. Massive Mannequin Chauvinism Will Get Somebody Damage
There’s this perception going round that AI fashions are getting so good that {hardware} can afford to be dumb. Sensors? The mannequin will determine it out from imaginative and prescient. Security limits? The coverage will be taught to keep away from them.
I name this Massive Mannequin Chauvinism. At our startup, it formed choices continually. And to be truthful, it wasn’t one particular person’s blind spot — most of us purchased into it to a point. The AI was genuinely spectacular, and it was straightforward to let that pleasure paper over {hardware} fundamentals.
One instance that also bugs me. We spent a genuinely very long time debating whether or not so as to add finish stops to the robotic’s joints. Finish stops. Mechanical restrict switches. A bit of metallic that bodily prevents a joint from destroying itself. Most simple security redundancy there’s.
The argument in opposition to: the AI coverage ought to be taught the joint limits. Finish stops are additional price, additional weight.
Anybody who’s completed {hardware} is aware of why this doesn’t maintain up. Finish stops exist as a result of software program fails. Fashions glitch. Insurance policies hit edge circumstances no one anticipated. When a language mannequin hallucinates, you get a flawed reply. When an actuator blows previous its joint restrict at full torque as a result of the coverage had one unhealthy inference step, you get a damaged machine. Or a damaged particular person.
The mannequin is likely to be proper 99.99% of the time. The top cease is for the 0.01%. Within the bodily world, 0.01% is the one quantity that issues. Even Tesla, with all its autonomy ambitions, nonetheless places brakes on the automotive.
2. Cease utilizing over-simplified analogies. They’re for fundraising, not for constructing.
Each robotics pitch deck has one. “We’re doing for robots what Tesla did for EVs.” “That is the iPhone second for embodied AI.” At our firm, the favourite was the hoverboard (平衡车). Humanoid robots would observe the identical price curve as self-balancing scooters: costly novelty → Shenzhen mass manufacturing → commodity {hardware} → all over the place.
A hoverboard motor simply must spin. That’s it. A humanoid robotic’s actuators should be terribly exact, explosively highly effective, immune to put on, and constant unit to unit. One actuator barely out of spec and the robotic walks flawed, or falls. Hoverboards, smartphones, no matter analogy you choose, none of them let you know something helpful about constructing a humanoid.
However “it’ll be like a hoverboard” is a narrative VCs get. Inevitable price discount, China manufacturing magic, billion-unit scale. Each hour spent on analogy debates was an hour not spent on the precise technical issues.
Analogies are compression algorithms. They make complicated issues easy by throwing away data. In a pitch deck, advantageous. In an engineering determination, the thrown-away data is often the half that kills you.
3. {Hardware} provide chain isn’t a process
A number of software program founders suppose provide chain is a process. Discover somebody who speaks Chinese language, level them at a manufacturing facility, examine the field. This is likely one of the commonest methods {hardware} startups get into hassle.
After I joined, there was nothing. No producer relationships, no cost phrases, no QC course of, no logistics pipeline. Constructing it meant meeting, parts, actuators, a number of Chinese language CMs for fabrication. Every one meant separate negotiations on pricing, high quality requirements, MOQs, manufacturing scheduling, throughout currencies, time zones, and enterprise cultures that function on fully totally different assumptions about how offers work.
That’s not “speaking to suppliers.” Manufacturing isn’t a service you purchase. It’s a functionality you construct. Your relationship along with your CM determines whether or not actuators are available in inside tolerance or 2mm off. Whether or not unit price lands at $800 or $2,400. If an organization’s {hardware} operations could be summarized in a single sentence, it doesn’t have a {hardware} technique. It has a hope.
4. There isn’t a such factor as “commodity” in robotics {hardware}
Probably the most harmful concepts going round: robotic {hardware} will turn out to be “commodity,” assembled from off-the-shelf elements by Chinese language producers identical to telephones, with the true worth sitting within the AI layer.
Not but. Not even shut. There’s no customary BOM for a humanoid. No off-the-shelf actuators that simply work for strolling. Each group constructing a legged robotic proper now could be designing customized {hardware}.
However when an organization buys into the “{hardware} is commodity” story, the harm is actual. The individuals constructing the bodily product find yourself with much less voice and fewer recognition than what they really contributed. Energy shifts to whichever perform will get the “defensible” label, irrespective of who’s doing the toughest work.
There’s a sample I noticed so much. I name it Schrödinger’s experience. When one thing goes flawed on the {hardware} facet, abruptly they’re not a {hardware} particular person, they do not know. When the engineering group says a redesign takes 4 months, abruptly it must be completed in 4 weeks. You possibly can’t have it each methods, and the engineers who’re really doing the work can see proper by means of it.
Our engineers constructed a robotic that walked. That was the toughest engineering the corporate did.
5. In a race, unhealthy R&D choices kill sooner than unhealthy luck
Everybody in robotics is racing. Capital is there, expertise is flooding in, the market is paying consideration. However a race rewards velocity, and velocity isn’t effort. Pace comes from making the proper calls quick.
The one largest mistake I noticed was getting caught on locomotion. Months burned, the robotic nonetheless wasn’t strolling proper, and in the meantime the fundraising window closed and rivals shipped demos. This wasn’t only a management name — the entire group, myself included, underestimated how onerous the issue was and the way lengthy it will take. The GitHub was stuffed with repos. From the skin it regarded like velocity. From the within it was movement with out convergence. Repos don’t ship. Demos ship. Merchandise ship.
The deeper challenge was determination high quality. Impulsive calls kill simply as quick as sluggish ones. Committing onerous to the flawed course doesn’t save time, it prices double, since you nonetheless need to undo it later.
R&D velocity isn’t repos or commits or hours logged. It’s how briskly you converge on one thing that really works.
6. 欲速则不达 — the extra you rush, the additional you fall behind
Our timelines have been a operating joke. It was at all times the robotic walks subsequent week. Each week.
When that’s the tradition, individuals begin chopping corners to hit unimaginable dates. Engineers write code with AI instruments with out reviewing it correctly. Sensors go onto the product with out calibration. After which the demo fails, once more, and the timeline resets to subsequent week.
That is what the Chinese language name 欲速则不达. Actually: need velocity, fail to reach. When unrealistic deadlines turn out to be the norm, the group doesn’t really transfer sooner. They only skip the steps that make issues work. And each skipped step comes again as a failure that prices extra time than the shortcut saved.
The harm goes past engineering. While you make guarantees to your contract producer primarily based on fantasy timelines, you burn the connection. A CM wants practical expectations to plan their very own manufacturing. A chaotic “transfer quick, break issues” mindset would possibly work in software program. It doesn’t work when your producer is allocating manufacturing facility ground time primarily based on commitments you may’t preserve.
A private word
I might have been a greater COO. Ought to have been firmer earlier in regards to the organizational issues, again once they have been fixable. Ought to have pushed more durable on practical timelines as an alternative of letting them slide. That’s on me. However I realized the place these strains are actually, and that’s one thing I take into no matter comes subsequent.
However I used to be there for the entire thing. First hackathon to final provider e-mail.
In case you’re a younger engineer at a startup: belief your instincts on physics. If the mathematics says the joint will break, write it down. Make the case formally. Don’t let the strain to maneuver quick bully you into ignoring what you recognize to be true. Your repute is constructed on what you ship, not what you promised.
If these six classes assist somebody, a {hardware} founder, a provide chain particular person, a forty-year-old mum or dad questioning whether or not to hitch a startup, then this was value writing.
I nonetheless consider in embodied AI. I simply consider it deserves {hardware} that’s as significantly engineered because the software program controlling it.
In regards to the Creator
Rui Xu is a {hardware} veteran primarily based in Silicon Valley. He beforehand served as COO of Okay-Scale Labs, a YC-backed robotics startup constructing reasonably priced humanoid robots. Earlier than that, he spent 18 years transport client {hardware} at Intel, Xiaomi, Lenovo, Amazon, and ByteDance, together with merchandise just like the Xiaomi Mi Field, Lenovo Sensible Show, and Amazon Fireplace TV. He writes about robotics, {hardware}, and the fact of constructing bodily merchandise at ruixu.us.
