Real unit costs, manufacturing lead times, and integration in the messy real world
It is tempting to think of a robotics startup as a software startup with a hardware wrapper, but the physical nature of the product changes the economics and the engineering in ways that are easy to underestimate. Every unit you build has a real, non-trivial cost, motors, sensors, structural materials, compute, and that cost does not disappear at scale the way marginal software cost does; it usually just improves gradually as you negotiate better component pricing and simplify the design. On top of that, hardware has manufacturing lead times: ordering custom parts, waiting on suppliers, and iterating on a physical design takes weeks or months per cycle, not the hours or days a software team might spend shipping and testing a change. This alone changes how fast you can learn from mistakes, and it means hardware mistakes are expensive to make twice.
Then there is the integration and reliability problem, which is arguably the hardest part and the one least visible from the outside. A robot that works reliably on a clean lab floor under controlled lighting can fail in ways nobody predicted once it is dropped into a real warehouse, farm, or job site, with dust, vibration, uneven surfaces, temperature swings, and untrained operators. These failure modes only show up in messy real-world deployment, not in a demo, which means a huge share of robotics engineering effort goes into hardening a system against problems you cannot fully anticipate until you are actually out there. This is fundamentally different from a software bug, which you can usually reproduce and fix from your desk; a robotics reliability problem might only occur in specific field conditions you have to go recreate.