Ten Things I’ve Learned About Building Robots That Survive the Real World
By Ted Larson
Right now, robotics is having a big moment. Not only is AI everywhere, but also demos look incredible and it’s easier than ever to make something that works in a lab. However, after spending nearly two decades helping startups and Fortune 500 companies bring robots and hardware products to market, I’ve learned a hard truth:
Most robots don’t fail because the idea was bad. They fail because early decisions quietly boxed the team into a corner they couldn’t escape.
If you’re building robots or even thinking about building one, here are ten things I’ve learned that separate robots that ship from robots that stall.
1. I’ve Never Seen Software Save Bad Hardware
I’ve worked on projects with genuinely great software teams. Strong algorithms. Clean architecture. Smart people. And I’ve watched those projects struggle because the hardware underneath simply couldn’t support what the software needed.
Motors introduce noise. Power rails sag. Sensors drift. Heat builds up. At some point, software runs out of room to compensate.
In my experience, hardware is the foundation, and software performance is strictly capped by physical reality. For example, I’ve seen teams demand extreme driving precision for a ground robot while using brushless motors without encoders.
Some engineers will argue that you can solve this with high-tech Field Oriented Control (FOC). But the reality is that FOC, no matter how sophisticated the code, simply cannot provide low-speed torque stability or precise positional holding without a feedback loop. No amount of brilliant software can invent data that isn’t being captured by a sensor.
If you ignore these physical constraints early, you pay for it later in jittery movement, failed requirements and the realization that no algorithm can fix a fundamental hardware mismatch when it comes to building robots.
2. Prototypes Have Lied to Me More Than Once
When building robots, prototypes are not only essential, but also, they’re misleading.
I’ve seen teams fall in love with a prototype built with hobby-grade parts and lab wiring, only to be shocked when production exposes thermal problems, EMI failures, or assembly issues no one saw coming. For example, one of the most common oversights is relying on consumer-grade interconnects for industrial or mobile environments.
In my experience, “I can demo it” and “I can ship it” are two very different milestones. We saw this clearly with one of our clients’ robots, which struggled with basic USB connectivity.
USB connectors are not physically robust as they lack screw-down mounts or locking mechanisms. It’s like if you’ve ever used CarPlay in your car and had the maps drop out or the music skip just because you bumped the cable or hit a pothole, you’ve experienced this failure in real life. On a robot moving through a dynamic environment, that momentary loss of connection isn’t just an annoyance; it’s a system-wide failure that can’t be “patched” with better code.
When building robots, if you don’t design for mechanical stability and signal integrity from the start, you’ll find yourself with a prototype that looks great on a lab bench but falls apart the moment it hits the real world.
3. I Treat Design for Manufacturing as a Starting Point, Not a Phase
One of the biggest mistakes I see in building robots is treating Design for Manufacturing as something you do after the design is finished.
In my experience, that always backfires as manufacturing constraints (part tolerances, assembly steps, test access, sourcing) should shape the design from the very beginning.
For example, one of our specialties is rescue jobs and a long time ago, we had a client who had built their product with a bunch of off-the-shelf parts.
While it initially saved money, when it came time to assemble the product in volume, the assembly process could not be streamlined. This is because the off-the-shelf parts were cumbersome to assemble and the time for assembling one unit was 30 minutes. Labor is super expensive and in this case, it was so expensive that it cost the same as the BOM (Bill of Materials). The factory they used referred them to us to redesign their product so that it could be manufactured in volume at a lower cost.
If you ignore them early, you pay for it later in redesigns, tooling changes, and missed launch windows.
4. Power and Thermal Problems Never Get Easier Later
I’ve yet to see a robotics project where power and thermal issues magically fixed themselves.
Power budgets that look fine on paper don’t survive real usage. Batteries behave differently under load. Heat accumulates in ways that aren’t obvious until you simulate and test properly. For example, OLogic performed detailed thermal simulations for the Snorble, allowing the team to optimize projector performance across a wide range of ambient temperatures. As a result, the device operated safely without compromising comfort or reliability.
When it comes to building robots, if power and thermal are treated as “later problems,” then they become launch blockers.
5. I Don’t Cut Testing Just Because Deadlines Are Tight
I understand the pressure. Every project has deadlines. But I’ve learned that cutting testing to hit a date usually costs far more later.
In building robots, especially for products that can’t easily be updated after shipping, testing is the last line of defense. Field failures don’t just affect devices, they affect trust, brands, and sometimes entire companies. For example, our Star Wars Force Trainer toy project was a great toy and big success, however once it’s shipped, there is no way to provide updates or anything as it is just a physical product.
Therefore, testing became even more important and the way the client ensured this was to have dozens of people in the factory in China play with it over and over and over with the goal of identifying weaknesses in the software or the out-of-box experiences.
Testing isn’t a luxury. It’s insurance.
6. I Think About the Supply Chain as Part of the Design
In building robots, and all areas of robotics design, component selection is never just about specs and price.
Over the years, I’ve watched parts go end-of-life mid-project, suppliers disappear, and geopolitical events wipe out availability overnight. If a single component can stop production, that risk is baked into the design. For example, back in 2024, a popular Chinese power supply company, Mornsun, was sanctioned by the US Government for selling parts to Russian drone manufacturers. As a result, the importation of these parts and availability of them in both the US and Europe dried up overnight and had a devastating impact on many shipping products.
Good hardware design includes alternate sourcing and long-term availability thinking from day one.
7. I’ve Seen Robotics Projects Fail Because Teams Worked in Silos
Robotics sits at the intersection of mechanical, electrical, firmware, and software. When those groups work independently, integration problems always show up late and they’re always expensive.
Mechanical decisions affect wiring and power. Electrical choices constrain firmware. Firmware exposes hardware flaws. Software finds timing and noise issues no one anticipated. For example, A client hired separate companies for mechanical engineering, industrial design, software, and electronics without strong coordination between teams.
Because if that it led to integration issues later in development, including insufficient space for electronics, batteries, and cabling, requiring last-minute mechanical changes. It highlights why cross-disciplinary collaboration early in the design process is critical for complex robotics systems.
The projects that succeed integrate early and communicate constantly.
8. I Treat Reliability and Compliance as Business-Critical
I’ve seen a single EMC failure force a board redesign, missed safety requirements delay launches by months, and durability issues trigger recalls.
These aren’t edge cases. They’re common. For example, we had a customer who was about to mass produce their product, however, they did not do a FCC compliance pre scan on their product until right before production was about to start. This was a problem because they were going to produce thousands of units and the device failed testing significantly and required substantial mitigation at the electronics level after both the BOM and hardware design were already finalized.
As a result, the production was delayed by two months so the redesigns and the validation could both be completed. If they did the compliance testing earlier in the development process, then these issues could have been identified and addressed proactively. Therefore, this project became another ‘rescue’ job for us.
In robotics, reliability, safety, and compliance aren’t just engineering checkboxes, they’re business-critical decisions.
9. I Judge Robotics Teams by What They’ve Shipped
Ideas are easy. Demos are easy. Shipping is hard.
When I evaluate a robotics team, both internal or external, I look at how many products they’ve taken through EVT, DVT, compliance, and production. Also, experience shows up in the questions people ask early, not in how impressive the demo looks. For example, a robotics company chose to hire an internal team instead of outsourcing to us. While they were super talented, they had never shipped out a robot before, which caused several challenges to surface. It all could have been avoided by having someone on the team who had shipped out a robot before.
Execution matters more than brilliance.
10. I’ve Learned That Early Decisions Compound Fast
Hardware doesn’t forgive early mistakes.
Every shortcut eventually shows up in blown budgets, missed ship dates, and painful redesign cycles. The teams that win are the ones who front-load the thinking, test like it matters, and design as if the product will one day be built by the thousands. For example, in one case, the client had a consumer robot that was made to use as a sophisticated developer platform. While the technical vision was strong, the resulting cost structure placed the product at a premium price point that proved difficult to sustain in the broader consumer market.
As the program matured, the team encountered many of the challenges typical of first-time consumer robotics launches, reinforcing how critical market alignment and product-shipping experience are alongside technical innovation.
Because when you build it right the first time, everything that follows gets easier.
Final Thoughts
In a world obsessed with software, robotics remains stubbornly physical. Software may define the logic, but hardware determines whether that logic survives contact with the real world. Additionally, I’ve learned that the best robots aren’t just clever, but they’re built for reality.
And that’s what it takes to make them last.
Abotut OLogic
With 20+ years of experience and over 150 successful programs, OLogic combines deep technical expertise with disciplined execution to de-risk hardware development. We operate with a strict 100% client IP ownership model, ensuring our clients retain full control of what they build.
