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 lately open-sourced its mental property. Xu first printed this text on LinkedIn. It was reprinted together with his permission.
I spent a 12 months 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 Collection A. By late 2025, it was over.
I’ve written concerning the good components earlier than. The hackathons, the storage power, the primary time the robotic walked. This time I need to write down what I truly realized. A few of these are industry-wide traps. Some we walked into ourselves.
1. Massive Mannequin Chauvinism Will Get Somebody Harm
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 selections continuously. And to be honest, 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 chunk of steel that bodily prevents a joint from destroying itself. Most elementary security redundancy there’s.
The argument in opposition to: the AI coverage ought to be taught the joint limits. Finish stops are additional value, additional weight.
Anybody who’s executed {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 instances no person anticipated. When a language mannequin hallucinates, you get a mistaken reply. When an actuator blows previous its joint restrict at full torque as a result of the coverage had one dangerous inference step, you get a damaged machine. Or a damaged particular person.
The mannequin could be proper 99.99% of the time. The tip 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.” “This is the iPhone moment for embodied AI.” At our firm, the favourite was the hoverboard (平衡车). Humanoid robots would observe the identical value curve as self-balancing scooters: costly novelty → Shenzhen mass manufacturing → commodity {hardware} → in every single place.
A hoverboard motor simply must spin. That’s it. A humanoid robotic’s actuators have to be terribly exact, explosively highly effective, proof against put on, and constant unit to unit. One actuator barely out of spec and the robotic walks mistaken, 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 value 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, nice. In an engineering choice, the thrown-away data is normally the half that kills you.
3. {Hardware} provide chain shouldn’t be a activity
A couple of software program founders assume provide chain is a activity. Discover somebody who speaks Chinese language, level them at a manufacturing unit, verify the field. This is without doubt one of the most typical methods {hardware} startups get into hassle.
After I joined, there was nothing. No producer relationships, no fee 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 “talking to suppliers.” Manufacturing shouldn’t be a service you purchase. It’s a functionality you construct. Your relationship together with your CM determines whether or not actuators are available inside tolerance or 2mm off. Whether or not unit value lands at $800 or $2,400. If an organization’s {hardware} operations will 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 change into “commodity,” assembled from off-the-shelf components by Chinese language producers identical to telephones, with the true worth sitting within the AI layer.
Not but. Not even shut. There’s no normal BOM for a humanoid. No off-the-shelf actuators that simply work for strolling. Each crew constructing a legged robotic proper now’s 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 operate 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 mistaken on the {hardware} aspect, all of the sudden they’re not a {hardware} particular person, they don’t know. When the engineering crew says a redesign takes 4 months, all of the sudden it must be executed in 4 weeks. You possibly can’t have it each methods, and the engineers who’re truly 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, dangerous R&D selections kill sooner than dangerous 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 shouldn’t be effort. Velocity 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 opponents shipped demos. This wasn’t only a management name — the entire crew, myself included, underestimated how onerous the issue was and the way lengthy it might take. The GitHub was filled with repos. From the surface it seemed like velocity. From the within it was movement with out convergence. Repos don’t ship. Demos ship. Merchandise ship.
The deeper difficulty was choice high quality. Impulsive calls kill simply as quick as sluggish ones. Committing onerous to the mistaken course doesn’t save time, it prices double, since you nonetheless must undo it later.
R&D velocity isn’t repos or commits or hours logged. It’s how briskly you converge on one thing that truly works.
6. 欲速则不达 — the extra you rush, the additional you fall behind
Our timelines had been a working joke. It was all the time the robotic walks subsequent week. Each week.
When that’s the tradition, individuals begin slicing corners to hit inconceivable 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 change into the norm, the crew doesn’t truly transfer sooner. They simply 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. Whenever 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 “move fast, break things” mindset may work in software program. It doesn’t work when your producer is allocating manufacturing unit flooring time primarily based on commitments you may’t maintain.
A private be aware
I might have been a greater COO. Ought to have been firmer earlier concerning the organizational issues, again once they had been fixable. Ought to have pushed tougher on practical timelines as a substitute of letting them slide. That’s on me. However I realized the place these traces 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.
Should you’re a younger engineer at a startup: belief your instincts on physics. If the maths 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 realize to be true. Your fame 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 mother or father 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 critically engineered because the software program controlling it.
In regards to the Writer
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 Good Show, and Amazon Hearth TV. He writes about robotics, {hardware}, and the truth of constructing bodily merchandise at ruixu.us.



