Moving fast in hardware: lessons from lab to $100M ARR

Simplify, Then Add Lightness

How to move fast when building for the physical world

When Colin Chapman said “simplify, then add lightness,” he was talking about racecars. Chapman was a legendary F1 engineer and founder of Lotus. They won races not by adding power but by removing everything that wasn’t load-bearing. He was so obsessive about weight that his engineers joked the cars were designed to fall apart the moment they crossed the finish line. Some of them did.

But the phrase is deeper than weight savings. It’s a design philosophy that maps onto almost every domain where complex systems must perform under constraint — which is to say, all of engineering, and most of company-building. If you’re building in robotics, aerospace, energy, defense, consumer electronics, medical devices, or automotive, this is for you.

I co-founded ClearMotion, a company developing automotive robotics that stabilize vehicle ride and handling, and we took it from a research prototype into volume production and >$100M ARR. One of the important lessons I learned is that speed in hardware development doesn’t just come from heroic effort. It comes from reducing the mass of the learning loop. Delete unnecessary requirements. Collapse handoffs. Pull uncertainty inside. Push complexity from hardware into software where you can.

I made a lot of mistakes that slowed us down. Here are my top 6 hard-earned lessons about how the best teams building physical products can move fast, along with stories of other builders doing the same.

1. The fastest teams start by deleting requirements

People talk about hardware engineering as if it’s slow by nature. Build cycles are slow. Tooling is slow. But most of what makes it slow is managing cross-disciplinary complexity. Requirement loads, inefficient experimental design, cross-functional distance, organizational drag. The teams that succeed are usually the ones that subtract.

Earlier attempts at active suspension — Bose’s electromagnetic system, Chapman’s own hydraulic version at Lotus — aimed at very high peak force levels. On paper it’s correct when you run the math: holding a two-ton SUV flat during max cornering requires enormous static force. But that requirement pushes you toward heavy, expensive, power-hungry architectures. Bose spent decades on the problem and never shipped. Chapman’s system added so much weight and complexity that it contradicted his own philosophy.

At ClearMotion, one of the most important technical choices we made was refusing to size the system for the rare, extreme on-road condition. We instrumented hundreds of cars to study actual driving profiles, not textbook edge cases, but how people actually drive — and designed around that reality. Today our fleet of customer vehicles collect data every day to better understand system usage. The result: our peak force requirement was ~20% of what others had targeted. That single subtraction opened a completely different design space. We could use a simpler architecture, which meant not just 90% lower cost but also much faster response, which resulted in better ride quality for the events customers actually experience every day. We were able to delete a number of components such as servovalves, manifolds, hoses and push most complexity into software. The tradeoff was that in a rare edge case —aggressive track driving in an SUV — the car would revert to conventional behavior. Customers didn’t notice that, but everybody noticed the ride.

The fastest teams don’t merely optimize within the spec. They rigorously interrogate which parts of the spec aren’t absolutely necessary from a first principles perspective. A surprising amount of engineering speed can come from this.

When NASA’s Apollo program was choosing how to get to the moon, most of the agency’s leadership favored either direct ascent, landing the entire spacecraft on the moon and flying it home (the obvious approach), or Earth-orbit rendezvous, assembling a large vehicle in orbit before heading out. Both approaches required a colossal booster and extreme lunar landing capability. A relatively junior engineer named John Houbolt became convinced that lunar-orbit rendezvous, sending a small, purpose-built lander down while the command module waited in orbit, was dramatically better. He was right, but he had to go around the chain of command, writing directly to the associate administrator, to get the idea taken seriously. NASA eventually chose his approach. It was a subtraction. By removing the requirement to land the entire return vehicle on the lunar surface, they eliminated the need for a much larger booster, could use existing technologies, simplified the thermal protection problem, and made the schedule plausible. Without that architectural subtraction, Apollo almost certainly would not have made Kennedy’s deadline.

You can see the same instinct in SpaceX’s avionics. They questioned a requirement the industry had treated as obvious for decades: every critical flight computer must use space-grade components. Space radiation-hardened parts are tested to standards like less than one failure per million parts and can cost 100x to 1,000x more than commercial equivalents. Worse, they’re often a generation or two behind in performance because of the long qualification cycles. SpaceX removed the requirement at the component level and instead designed for low system failure rates through triple-redundant voting architectures, conceptually similar to how a RAID array makes unreliable disks into a reliable storage system. The result was much lower cost, faster iteration, broader part availability, and the ability to upgrade compute on a cadence closer to the commercial world. The heritage aerospace approach optimized each piece for perfection. SpaceX optimized the system for resilience and speed of development. Different spec, different design space.

For 18 years, aerospace teams tried to win the Kremer Prize for human-powered flight, most failing in the same way: they built carefully engineered aircraft around an implicit requirement no one questioned: the aircraft must not break. That requirement seemed so obvious it was invisible. But it pushed each team toward heavy, expensive designs that took months to build, and when they inevitably crashed on early flights, it took months to rebuild. Each failed attempt cost teams a year. No one could iterate fast enough to learn.

Paul MacCready, a Caltech aeronautics PhD and champion glider pilot, deleted that requirement. He didn’t build a better aircraft. He built a disposable one. The Gossamer Condor was made of Mylar film, aluminum tubing, piano wire, and tape. It weighed 55 pounds. It looked absurd. It crashed constantly. But when it crashed, his team could repair it in hours and fly again, sometimes multiple times in the same day. Over the course of development, the Condor went through more than 400 test flights and over 12 major design modifications. His competitors ran one or two experiments per year. By deleting the unexamined requirement of structural durability, he opened a completely different design space, one where the rate of learning mattered more than the quality of any single attempt. A year after starting, the Gossamer Condor completed the prize course that had defeated everyone else for nearly two decades.

The hard part is that subtraction requires courage. Often it requires a bet on the unknown. Adding requirements feels safe. But in early-stage hard tech, overdesign kills more companies than under-design. Bose’s active suspension was technically extraordinary but a commercial dead-end. Start with the right spec.

2. Good prototypes are experiments that answer the next unknown

One question I sometimes get from hard-tech founders is how we structured our milestones, and the fundraises attached to them. My general answer is: design a sequence of experiments where each one retires the next most important ri