Lessons from 8 Years of Building Robots

Hello! This is a special edition of Hardware FYI. We recently had the chance to talk with Dexterity, a robotics startup that just launched Mech, an industrial-grade "superhumanoid" robot built for real-world warehouse logistics.

A few quick notes on Dexterity:

• Founded in 2017 by former Stanford labmates

• Raised $290M from Lightspeed, Sumitomo, and others

• Learned fast by shipping pilots and keeping what worked

• Eight years of development led to Mech, today’s warehouse-ready robot fleet

Below is our conversation with founding engineer Robert Sun. If you’re interested in learning about how robots are developed commercially or just like seeing complex systems come together, we think you’ll enjoy this one.

---

Origins & Development History

What were you originally trying to build, and what were some of the early discoveries that shaped the company's direction?

We started with a broad mix of projects: robots that moved bread trays, systems that singulated parcels, and robotic arms picking cosmetics and toys from cluttered bins. At the core, they were all essentially the same job: moving items from point A to point B to streamline logistics tasks like sorting, fulfillment, and delivery.

Many robotics companies made picking their core business strategy, and we did too at first. But over time, we found that more complex, physically intensive tasks like truck loading and palletizing offered a better path forward. These are harder problems, but also more clearly valuable to the customer, and there's no ambiguity where the robot adds value.

As we built more systems, we went through phases of discovery not just in robotics, but in the business around them. There's a reason robots today still aren't widespread outside tightly controlled manufacturing environments: real-world conditions are unpredictable. Traditional robotics thrive when executing choreographed routines under controlled conditions, performing tasks repeatedly, reliably, and efficiently.

The logistics environment poses a unique challenge because it constantly changes. No two items are exactly alike, and tasks frequently present unknowns. That variability makes it nearly impossible to just buy a robot, program it once, and expect it to stay useful. You either reshape your operations around automation—like Amazon did with Kiva—or you develop highly adaptive systems. So far, nobody has fully cracked tactile manipulation at the level required by real-world logistics.

Iterations Toward Mech

We went through a few phases of hardware design/development. First, we built using off-the-shelf components with whatever was available on the market. It worked, but it was expensive and required significant design effort to retrofit into each customer’s warehouse. The solution technically worked, but it wasn’t scalable. Too much custom engineering per site for too little gain.

Next came our “IKEA flat-pack” phase using standardized containerized systems you could deploy cell by cell. Better, but still required customers to plan out large amounts of floor space and infrastructure.

The idealized form of the system is now Mech: a mobile base with two high-torque arms that moves between workstations. It handles palletizing, singulation, and truck loading without needing to reconfigure the warehouse.

What we’ve realized through these iterations is that the hard part isn’t the robot. It’s everything around it: infrastructure, material flow, IT integration, PLCs. Customers don’t want a kit of parts—they want a drop-in system that plays nicely with their existing operation and minimizes the cost and complexity of “site upfit.”

We also had to answer a deeper question: are we a robotics company, a software company, or both? The reality is, if you want to deploy robots that actually deliver ROI at scale, you need to be full-stack. That means we build everything: the robot hardware itself, custom mechanical designs, camera systems, control algorithms, perception pipelines, high-level and long-term decision-making, and the full software stack—APIs, data infrastructure, and enterprise interfaces. That’s the only way to make robotic systems easy to adopt for both operations teams and large enterprises.

That doesn’t mean we do everything in-house, and we’re not machining every part ourselves. For key subassemblies like actuators and motion components, we rely on trusted manufacturers like Kawasaki and Hiwin. But the system architecture, the integration, and design philosophy are all ours. We do whatever’s necessary to deliver a robust, scalable product in the real world.

You've said it took 8 years of product development to reach the current design. Could you walk us through some learnings that forced you to rethink your approach?

There have been countless learnings (probably on the order of thousands), but two stand out:

1. Rethinking suction gripping and infrastructure dependency

Suction gripping is highly effective, but traditional industrial automation depends on compressed air systems (usually venturi-based) which require a lot of infrastructure. Most logistics sites don’t have that kind of built-in compressed air, if any. And imagine all the tubing, piping, and systems you'd need to run throughout the warehouse just to support your robots—let alone the compressors, power, and other supporting infrastructure. We learned early on how impractical that setup was, so we went the other way: build everything into the robot itself. Onboard vacuum pumps, modular gripping heads, safety systems, and quick-change adapters without facility retrofits and external dependencies. Just drop it in and go.

2. Bridging the gap between industrial reliability and AI-grade compute

Another big challenge was relying on external vendors for AI-grade compute, vision, and perception systems. The industrial world just hasn’t kept pace with the speed of the AI ecosystem. So you end up with a disconnect: rugged industrial hardware that’s built to last but can’t handle modern AI workloads, and AI-grade compute and vision systems that are powerful, but too fragile for the realities of an industrial environment.

Eventually, we realized that if we wanted something that could handle real AI workload and survive in industrial environments, we had to control the architecture end to end. So we started building key systems in-house—compute, cameras, grippers, the whole stack. When we did source from vendors, it was with close integration to meet the performance and reliability we needed.

Defining Product Requirements

Defining the engineering requirements was tricky especially early on. Like with most robotics companies, the hardware and software specs were tightly coupled to what the product needed to do, which was itself tied to what the customer wanted. But that’s the problem: customers don’t always know what to ask for. And to be fair, that’s not their fault—robotics is new, and integrating it into real-world operations is complex.

So over years of pilots and deployments, we figured out which specs actually mattered. Some features we thought were critical turned out to be irrelevant, and others we hadn’t even considered became non-negotiable:

• Environmental robustness: temperature and humidity tolerances matter a lot more in logistics than we expected.

• Safety: not just in terms of sensors, but how the system behaves when something goes wrong.

• IT integration: every customer has their own backend with APIs, networks, and security requirements. The robot had to fit into that ecosystem.

• Modularity: we needed a platform that could upgrade over time. both in hardware and software, without a full redesign.

One of the biggest surprises was that some of the most critical requirements had nothing to do with the robot itself. Feeding it with product, coordinating upstream and downstream material handling, syncing with warehouse systems—all of that had to be designed too. These are full-stack system problems, not just robotics problems.

Walk us through Mech’s technical specs and key design details.

Mech is our first true mass-market platform. It’s built to scale, both for us and for customers, and can handle a wide range of high-value logistics operations. Think of it more like a superhuman logistics worker—one associate can simultaneously manage and monitor up to 10 Mechs!

It starts with a mobile base featuring four independently driven and steerable wheels, and the ability to handle 14° ramps without assistance. The base runs on battery power for mobility, and when stationary tasks like truck loading require more power, it can be plugged in to support the full arm load.

The robot is equipped with two 8-degree-of-freedom arms, each capable of lifting 35 kilograms. At full extension, the system reaches a 5.4-meter wingspan thanks to a patented shoulder joint and second elbow that give it a high degree of dexterity in confined spaces. Mech drives each joint in full torque control at 1–2 kHz, an order of magnitude faster than the 100–400 Hz loops on most industrial arms. That bandwidth lets the controller sense an impact and shift the joints into low‑torque compliance even during high-speed motion and sudden hard contacts.

Internally, Mech runs custom AI compute for real-time control, perception, and planning. Even the camera interface is custom: we moved away from USB (reliability issues with temperature fluctuations and shocks in the field) to a high-speed GMSL2 architecture, routed through custom PCIe cards we designed to hit the reliability and performance we need. These cards give us precise control over the cameras, including dynamic switching of frame rate and resolution on the fly. These capabilities just don't exist in standard SDKs.

The grippers are proprietary and closely tied to our force control stack. We built our own force sensors because off-the-shelf ones were too fragile or too sensitive for logistics. Ours are robust and tuned to detect meaningful load changes while handling real-world payloads. We also integrated vacuum pass-through directly into the force sensor, and it’s actually the first system we know of to do that. It eliminates the mess of external routing and gives us deterministic, reliable suction without compromising mechanical integrity.

It’s all industrial-rated: 60kg payload, operates from 32° to 122°F, 90% humidity, up to 5,000 ft elevation, and a 10+ year mean time between failure (MBTF).

What does "real-world sturdiness" actually mean for a robot like Mech?

Robustness for a robot like the Mech means surviving a very specific, and extreme set of environmental conditions. In industrial settings like a warehouse loading dock, that can include designing the robot to handle shock and vibration levels approaching military-grade specs, temperature swings from -10°C to 55°C, and up to 90% condensing humidity. The robot needs to operate through all of it without performance degradation. That level of environmental resilience is non-trivial to design for.

Fun fact: In automotive environments, robots often need to be explosion-proof, especially in paint shops where volatile organic compounds are constantly in the air. That means positive pressure in every sealed joint to prevent gas ingress and eliminate ignition risk. While our current deployments don’t require explosion-proofing, we’re moving toward similarly harsh conditions like water spray, rain, high humidity tests. The hardware needs to be sealed and rugged enough to maintain reliability through all of it.

Fleet & Operations

How would you segment the warehouse‑automation sector, and where does Mech’s platform compare against competing solutions?

Warehouse logistics, and really most of the supply chain, is all about moving objects from one place to another, just in a huge variety of ways. There’s a lot of tactile manipulation involved, and the nature of the work changes depending on whether you’re dealing with small items going into bins or large, bulky boxes being loaded onto trucks.

We focused early on not just where robots could work, but where they should—the kinds of jobs that are tough for humans to do at scale. High repetition, bad ergonomics, heavy lifting, awkward motions. That’s exactly where Mech is built to perform.

This isn’t the only use case we go after, but it’s one of the most obvious ones. When you’ve got a specialized robot that’s fast, dexterous, and strong, it’s immediately clear why it should be handling these kinds of tasks in warehouse environments. Mech can move boxes that are over OSHA limits for human workers. It can use both arms independently or in tandem to deal with heavier, bulkier, wheeled items. It works across object types (boxes, bags, parcels, irregular shapes) and handles everything from palletizing and depalletizing to container loading and mixed manipulation. It’s built like a super-humanoid, purpose-built for warehouse conditions.

A lot of other companies have focused on bin picking and order fulfillment, and those are hard problems too. But they’re also hard to scale cleanly. We leaned into the problems where hardware can actually be the multiplier, and where it’s obvious to everyone why a robot should be doing the work.

There’s been a lot of interest and technological development of humanoid robots recently. What do you think about form vs. function?

There’s a lot of excitement around humanoid robots and for good reason. A single machine that can replicate human labor across a wide range of tasks is a very compelling idea. And I don’t doubt that if you could truly build a perfect humanoid, it would be able to do a lot. But that’s an extremely hard challenge, mechanically speaking—never mind the AI, the speed, or the cost required to get it done.

When it comes to the kinds of tasks that actually matter—things like logistics, manufacturing, construction—you begin to ask: is the human form factor even the right answer? It’s kind of like asking why we paved roads instead of building better mechanical horses. Once you’re designing infrastructure from scratch, you don’t try to match the past. You build for efficiency and scale.

In the same way, a lot of the real-world tasks we care about are heavy, awkward, and not particularly ergonomic. They’re not best handled by a robot shaped like a person. But they’re also not always a fit for one-off, task-specific machines either. The sweet spot ends up being something in between: a system general enough to handle variation, but specific enough to outperform humans on real work and do it at scale.

---

Looking back, what's something you wish you knew before starting the company?

If there’s one thing I wish I understood early on, it’s that most people building something new are figuring things out as they go. Very few have it all mapped out from the start. Mistakes are inevitable, and getting things wrong is part of the process. What matters more is how you respond and whether you’re able to learn quickly and adapt. That resilience ends up being more valuable than getting every decision right the first time.

---