How US Hardware Startups Will Outcompete China | Pari Singh, Flow

Relentless 1h13 8 min #54
How US Hardware Startups Will Outcompete China | Pari Singh, Flow
Watch on YouTube

Summary

  • Pari Singh is the founder and CEO of Flow Engineering, a company building software that fundamentally changes how complex hardware is designed. Flow’s mission is to reinvent the way humanity designs the most important machines, from rockets and nuclear reactors to robotics and EVs. The company emerged from Pari’s earlier venture, a rocket engine consultancy, where he and his team discovered that the real bottleneck in engineering isn’t any specific technical problem, but the outdated, waterfall-based way the entire industry works.

The broken state of hardware engineering

  • Engineering today operates on a waterfall model inherited from the mid-20th century: write all requirements upfront, decompose them top-down into a Gantt chart, design, test, and ship. This worked when systems were relatively simple, but it breaks down catastrophically as complexity increases.
    • The core issue is that for highly complex systems, the “unknown unknowns” dwarf the knowns. You can’t decompose requirements from the top down because you don’t yet know what the subsystems need to do, since everything affects everything else in parallel.
    • Industries that faced similar complexity explosions already made the shift: software moved from waterfall to agile in the 2000s, chip design went from 100 transistors to over a billion, and gaming moved from linear development to iterative approaches. Hardware engineering is the next and most overdue transition.
    • The traditional aerospace primes (Boeing, Lockheed) still operate this way. The Boeing Starliner vs. SpaceX Dragon comparison illustrates the problem: Starliner was more expensive, took longer, and was lower quality precisely because it applied a waterfall approach to a system that demands an iterative one.

The new way: iterative, bottoms-up, agile hardware development

  • The new generation of hardware companies (SpaceX, Anduril, Joby, Figure) operate more like software companies than traditional manufacturers. They work in short cycles, design-build-test-fly repeatedly, and integrate aggressively thousands of times rather than in one big program.
    • SpaceX’s real competitive advantage isn’t just vertical integration or Elon Musk’s leadership; it’s their fundamentally different approach to developing hardware. They iterate in thousands of small cycles rather than one 10-year program.
    • The Apollo program is actually a historical example of this approach done right: NASA didn’t write a million requirements upfront. They went bottoms up through Mercury, Gemini, and Apollo in roughly 25 iterative cycles, learning and leveling up each time, accepting failure as part of the process.
    • The key cultural shift is from “analysis paralysis” (trying to anticipate and derisk everything before building) to “what can we produce in 3 months?” Learning only happens by doing, failing, and iterating.

Agile vs. iterative: a critical distinction

  • Pari draws an important distinction between two terms people conflate:
    • Iterative means taking a bottoms-up approach, shipping quickly, and improving continuously. SpaceX and Radiant Nuclear are deeply iterative, but their top-level requirements (e.g., minimize cost per kilogram to orbit) are fixed and well-understood.
    • Agile means continuously questioning whether your top-level requirements are even correct. A drone company, for example, doesn’t yet know what range, capability, or autonomy level it needs, and the battlefield keeps changing. Such companies need to be both iterative and agile.
    • Most hardware companies need to be iterative; some also need to be agile depending on how uncertain their requirements are.

The China question and why this transition matters geopolitically

  • Pari believes there is roughly an 85% chance of war between the US and China within five years, based on Xi Jinping’s explicit rhetoric, domestic US political dynamics, and the historical pattern of rising vs. declining superpowers.
    • China is ahead in most hardware verticals: shipping, nuclear (SMRs), solar, batteries, EVs, robotics, and humanoid robotics. They operate at extraordinary intensity (beyond 996 work culture) and have more control over global supply chains than commonly acknowledged.
    • China’s approach is “hardcore mode” with extreme consequences for failure, which lets them push through on suboptimal tools and processes. But they haven’t yet mastered the sliding scale between aggressive iteration and safety/reliability, as evidenced by recent rocket launches crashing into villages.
  • The US can win on two dimensions:
    • Reliability and safety: If China ships first but their products are unsafe (SMRs that blow up, EVs that kill passengers), the US wins by being slower but an order of magnitude more rigorous. The FAA, while demanding, is still innovation-progressive compared to Europe’s EASA, which Pari describes as a paperwork exercise.
    • Autonomy and AI (the “new game”): The real next-generation advantage isn’t having the best individual hardware piece (best tank, best drone) but having all systems talk to each other as one autonomous cluster, with superior AI orchestrating drones, humanoid robots, submarines, and tanks as a unified mesh. This is where software defines hardware rather than the reverse.
      • Anduril is a key example: people misunderstood them as “just doing Boeing faster,” but they’re actually a software company whose core innovation is the layer that makes hardware components communicate.
      • The risk is a future where autonomous systems make life-or-death decisions faster than humans-in-the-loop can respond, creating a sci-fi scenario where the side that turns on full autonomy first has an advantage but also risks losing control.

Three eras of manufacturing

  • Pari sees the history of manufacturing in three eras, with a fourth and fifth on the horizon:
    • Era 1: Analog (1940s–1980s): Pen and paper, drafting tables, physical testing. Apollo and the Manhattan Project. Low complexity, manual processes.
    • Era 2: Digital (1980s–present): CAD, spreadsheets, simulation. Space Shuttle. Each vertical got its own software tools, enabling much higher complexity.
    • Era 3: Iterative/Autonomous (now beginning): Software is invading hardware, blowing up complexity by 10–100x. A watch is now a computer on your wrist; a car is a self-driving computer on wheels. This demands a bottoms-up, cross-functional, deeply iterative approach. Falcon 9 is the defining product of this era. Flow exists to enable this transition.
    • Era 4: Computational/Generative (future): Engineers won’t manually draw the 15,000th valve variant. Much of the design will be computationally generated.
    • Era 5: Software is hardware (further future): The distinction between software and hardware dissolves, converging toward nanotechnology-like paradigms.

Flow’s origin story and three philosophical pivots

  • Pari started the company at 21 as a rocket engine consultancy, not a software startup. They were the fastest hybrid rocket engine design consultancy in the world, going from requirements to detailed design in 2.5 hours instead of the industry standard of 12 weeks, using an internal platform they built called Flow.
    • Pivot 1: From hardware consultancy to software platform. They realized they hadn’t built an automation tool; they had built an abstraction layer that let them start with simple low-fidelity models and increase complexity iteratively multiple times per day. They realized every company would need to invent this themselves (taking ~10 years) or Flow could productize it.
    • Pivot 2: From “build the tech and they will come” to “behavioral change is the real problem.” They built the platform, took it to companies like McLaren and Rolls-Royce, and got enthusiastic responses. But when they actually entered these companies, they found teams overwhelmed, months behind on current projects, and unable to adopt the new way of working. The technology alone wasn’t enough; the real problem is cultural and behavioral change.
    • Pivot 3: From visionary platform to solving today’s acute problem (Trojan horse strategy). A small US rocket company called Stoke (5 people at the time, now raised hundreds of millions) told Flow: “This is the future of all engineering, but if you don’t solve our most acute problem today—requirements management—it doesn’t matter.” Flow didn’t want to build a requirements management tool; they wanted to build a revolutionary new development platform. But they built requirements management as the first app on their platform, and it worked. Every design partner started using it that same week with live data. Once they understood requirements through Flow’s lens, they could understand the whole new way of working. Flow thinks of itself as a new type of development platform; customers think of it as “requirements management plus.”

The El Segundo market and timing

  • Flow initially sold to European incumbents who had no real impetus to change. The breakthrough came from the “El Segundo” ecosystem: a new wave of next-generation hardware startups in the US that were already culturally aligned with iterative development and desperately needed better tools.
    • The strategy is to make these new companies so successful that they make the legacy primes look like dinosaurs, forcing the rest of the industry to adopt the new way of working. This mirrors what happened in software: Google, Facebook, and Twitter developed software so much better than IBM and Oracle that the old guard eventually had to adopt GitHub and agile methods.
    • Pari is bearish on traditional primes over the next decade, predicting they will die out as this new way of working becomes dominant.

The software-for-hardware market opportunity

  • The tools used by today’s most innovative engineers (rocket scientists, roboticists, nuclear designers) are stuck in the dark ages. The CAD/PLM market is an oligopoly (Siemens, Dassault, PTC, Autodesk) with software conceived in the 1970s–80s. Systems engineering is dominated by IBM.
    • These incumbents can afford to have terrible software because they’re deeply entrenched and sticky. The generational shift from waterfall to agile rewrites what companies need from their software, creating a once-in-40-years opportunity to rebuild the entire stack.
    • What separates winners in this market is taste: building software that end users love, not just that buyers approve. Flow’s deep commitment to UX quality and intuitiveness is a deliberate differentiator.

Building a special forces culture

  • Flow deliberately built a “special forces” culture rather than an “army” culture. The framework Pari uses to evaluate people:
    • Zero-order people (~80%): Default career track. School, college, job, promotion, retirement. Looking for 9-to-5 and balance. The world runs on them.
    • First-order people (~15%): Classic high achievers. McKinsey, investment banking, Google, MBA. Ambitious, high-performance, typically become CEOs of large companies.
    • Second-order people (~5%): The people who change the world. Their defining trait is that at every stage, their personal development accelerates. Critically, they’re willing to take a local hit (lower pay, worse location, less seniority) in exchange for a steeper growth slope. Very few people make this trade.
      • Pari believes hunger and determination matter more than raw IQ. Smarter people tend to see more ways things can go wrong and become risk-averse; determined people see what could go right and act.
      • Flow’s entire team of eight people at Series A was aggressively profitable, and they win head-to-head against competitors with HR teams three times their size.

Pari’s personal philosophy

  • Pari’s life purpose is to maximize the positive impact he can have, which he’s committed to through reinventing how physical things are designed. He increases his scope until he’s underestimated, then proves people wrong.
    • He references the parable of the Chinese farmer (“we’ll see”) as his framework for dealing with challenges: every setback and breakthrough is part of a journey whose ultimate outcome is still unknown.
    • On finding the right problem to work on, he challenges the idea of spending years figuring out the optimal path. Instead, he advocates for locally optimizing based on what you can contribute today, then continuously reassessing in tight feedback loops—the same iterative philosophy that Flow applies to hardware development.
Back to Relentless