“This could be a mass extinction event”: Pari Singh on why legacy manufacturers must change or die

Fast forward nine years, and Flow Engineering is now the operating system for the next generation of physical engineering, relied on by the likes of EV giant Rivian.

In this episode, Pari breaks down why the industry is at an inflection point, why the biggest threat to legacy manufacturers isn’t technology but culture, and why he believes the vast majority of physical engineering work will be automated by AI within the year.

We also get into what separates elite engineering teams from average ones, and the single characteristic he now hires for above everything else.

Carlos: I want to hear the very beginning, because I still remember those days – the very first day I met you at a Seedcamp event. You were wearing a NASA shirt, and that image is dubbed in my mind. You came in with the boldest idea, and we loved it. Where you are today is very different from where you were back then. Maybe, just for the audience, walk us through what you were doing – university, your first job, how did this all come to be?

Pari: I’ll tell you what we pitched Seedcamp, because it was insane, and then I’ll tell you how we got there. When we came to Seedcamp, we pitched a rocket company — the world’s fastest design consultancy for rocket engines. The fastest engineering consultants in the world could design a rocket engine from requirements to detail design in about 12 weeks. We could do it in two and a half hours. That was basically the pitch we presented to Carlos, Reshma, and the entire Seedcamp crew. The vision was actually to build a European SpaceX, and to use that as a secret sauce to go design rockets.

So how did we get there? I’m a mechanical engineer by training. I became a mechanical engineer because I wanted to build rockets, airplanes, cars, and nuclear — things that really mattered to people. Then I went into industry, to companies like BAE Systems and BP. And what I saw in production kind of broke my heart. We get these unbelievably smart, high-passion, high-IQ 21-year-olds, and for the first two decades of their career, we ask them to make one decision: do you want to be an Excel monkey, a CAD monkey, a simulation monkey? These engineers are essentially reduced to digital manual labor. A CAD engineer will basically design the same type of model again and again and again,  spending 10% of their time on highly creative engineering work and 90 to 95% just doing the same rote tasks over and over.

It was really clear to me, coming from a software background too, that all of this work is automatable. Someone should be finding a way to automate it, to enable engineering teams to move faster. If you could automate that, you could cut something like 80% of the R&D cost out of these enormous programs.

That was the founding thesis: engineering is broken, it’s extremely manual, there will be ways to automate it, and if you can automate it, you can have a huge commercial impact on both speed and development cost. We thought, no one’s doing this on rockets, so we’ll do it – and then someone will do it on cars, someone on wind turbines, someone on nuclear reactors. We’ll trigger a domino chain reaction, and 10 to 20 years from now the entire world will be different.

Carlos, Reshma, and the team were very gracious in hearing a 21-year-old with no real-world experience come in and say how he was going to change engineering. They said, “You should go do that rocket thing. But if the rocket thing doesn’t work out, I wonder if you could sell the software? Go to companies like McLaren and Rolls-Royce and help them go faster.” At the time, I thought that was the stupidest idea I’d ever heard. Why would I want to be a software company? Hardware’s cool. I’m a mechanical engineer — I want to do real things.

Zoom forward eight or nine years, and here we are: me building a software company, selling into next-generation rocket, nuclear, automotive, and other world-changing companies, helping them develop faster.

Carlos: You’ve recently raised a huge round from an amazing investor, and the journey isn’t even fully there yet. One of the interesting things is not only your arc from hardware to software, but the industry’s arc too. A lot has changed, and you like to refer to this as the three eras. Maybe walk us through the core problem — where are we today, not only in terms of the rote work of engineers, but also where we are as a society in how we manufacture things?

Pari: The engineering industry, the way I see it, comes in three distinct eras.

The first was the analog era: Think NASA and the moon missions. Think the black-and-white era when people were drawing with pen and paper.

The second was the digital era: The era of the Space Shuttle, the Ford Focus. When we moved from blackboards to spreadsheets, from pen and paper to CAD, from physical testing to simulation. That is the era Europe is largely in today, and has been since roughly the 1990s through the 2020s.

What we’re seeing take off today is a new era: the iterative era, or the systems era. When I think about this era, I think about companies like SpaceX, Figure, autonomous vehicle companies, reusable rockets, humanoid robots. In this era, complexity is significantly higher, and because of that, we can’t afford to put everything into a big Gantt chart, plan it out over three years, and hope for the best. No one has designed a nuclear reactor like this before. Humanoid robots involve such complex software-hardware integration that you can’t just think about it and then execute. Autonomous vehicles require insane amounts of testing, both on the engineering side and to ensure they’re road-safe and road-legal.

In this era, it’s really all about cross-functional collaboration. In the digital and analog eras, mechanical engineers kind of ruled the show –  a rocket is really a structural problem with some fluids and combustion. But what percentage of a Waymo is a mechanical problem? About 1%. Waymos, humanoid robots, reusable rockets, these are really software problems. It’s how the software, hardware, mechanical, electrical, firmware, regulatory, and systems layers all come together that makes it genuinely hard.

In this era, you need a new kind of platform that glues these different types of engineers together; one that enables teams to make a change in one place and immediately see the impacts cascade across others, then rapidly iterate.

Carlos: Do you find that companies still using digital-era tools are going to be insurmountably incapable of moving to the iterative era? They have a suite of disconnected tools, licenses, and employees trained on them. Is there a bifurcation coming — between companies born in an era where everything is connected through tools like Flow, and those stuck in the digital era who will simply be left behind, like so many manufacturing companies of years past?

Pari: I’ll try to find the right answer here. There are two really fundamental changes in the iterative or systems era.

The first is a cultural change: a move from old-school waterfall to new-school Agile. That’s a transformative change with lots of second-order implications.

The second is exactly what you’re describing, Carlos. It used to be that siloed engineering teams could make things work. Now it’s about cross-functional collaboration. That too is a cultural change.

Let’s break both down. If you look at how NASA works versus how SpaceX works, they’re extremely different. NASA will kick off a new program – say Artemis – and say, “This is very complex, so the way to reduce complexity is to think about it.” They’ll hire a bunch of people, put them in a room for five years, and call it requirements analysis phase. Europe, by the way, is still largely stuck in this analysis paralysis era. The underlying assumption is that you can think your way out of very complex engineering problems. That used to be true 30 or 40 years ago, but it’s no longer true, because if you haven’t designed your fusion reactor or your reusable rocket yet, you simply can’t think your way out of problems you haven’t encountered.

The best companies in the world have taken a software-like approach: it’s really based around iteration. When SpaceX designs a rocket, they don’t say “let’s imagine the dream rocket and design it right the first time.” They ask: what are the biggest risks? Stage separation? Landing? Then they build specific prototypes around those risks as quickly as humanly possible, learn by doing, expect failure, and understand that the heritage built through iteration will vastly exceed what you can learn by thinking.

When SpaceX tackled reusable rockets, they built something called Grasshopper – a rocket that went up a few feet, hovered, came back down, then went up a hundred feet, hovered, came back down. Bit by bit, design, build, test, iterate. That’s the chant of these new organisations.

This is especially important when software enters the loop. Waymo and humanoid robots are really software problems, and software timescales are very different from hardware timescales. What I’m seeing is that more and more hardware companies are actually becoming software companies with some hardware attached. Waymo is a great example — most of the complexity is in the algorithm, the software, the self-driving stack, and the testing around it. Far less of it is in the Jaguar vehicle that implements it. The best teams either sync to hardware timescales, or they let software iterate daily and find ways to map that to hardware cadences.

Carlos: But there’s a challenge. When I look at your roster of customers, which includes companies like Rivian, these are cutting-edge companies with, you’d assume, cutting-edge culture and philosophy. What I can’t figure out is: is this a mass extinction event for the NASAs and GMs of the world, simply because they can’t keep up? And how are you building your product – to serve both camps, or more to the Rivians?

Pari: I’ll answer directly: I believe this can be a mass extinction event.

The closest analogy is what happened in the software industry. Thirty years ago, it was dominated by IBM, Microsoft, SAP – very large, very waterfall-driven companies. Then in the 1990s and 2000s, YC happened, and you had new companies building quickly with the Agile manifesto. When IBM and Microsoft looked at Figma, Twitter, Facebook, they said, “These aren’t real companies.” What happened is that the new market – highly iterative, shipping to production three, four, five times a day – became the mass market. The old guard had to decide: do we move from waterfall to agile, or do we go extinct? The vast majority didn’t make it. But the legacy companies that identified this required a top-down cultural mandate. Those were the ones that survived.

A good example in this industry: three years ago I would have said 100% of the legacy OEMs were destined for extinction, and SpaceX, Rivian, Tesla, Joby, Figure were the new GMs and GEs of the world. What surprised me (pleasantly!) was Ford. Ford is the archetypical old-school automotive OEM. When Tesla arrived, their response was, “This isn’t a real company.” Then Tesla’s market cap exceeded Ford’s. Still: “Not a real company.” Then Tesla exceeded the combined market cap of all automotive OEMs. Still: “Not a real company.”

Then BYD happened. BYD is one of the largest automakers in the world – a Chinese OEM producing incredibly good vehicles at incredibly low prices, at insane scale. That was the genuine existential threat that caused Ford to pivot. And Ford actually pivoted well. When you move to EVs, you become a software company. When you become a software company, you have to be agile. Ford made that change.

Other OEMs have had more mixed results. But I do think it’s possible – if a company takes a genuine top-down mandate and says “this is an existential crisis, we need to rethink how we work” – to stay relevant.

Carlos: Walk us through how your product helps with that. If I go to your website, I see requirements management, architecture, traceability, continuous V&V, test cases, regulatory integrations (and a new AI section). What is Flow doing to help companies succeed?

Pari: The best way to describe it is to describe the field we operate in: systems engineering.

When you’re a hardware company, you have mechanical, electrical, software, and regulatory engineers all working on one system. Rivian’s R1T is one complex system, fragmented across all these teams, who need to collaborate very deeply. How do they do that? Through something called requirements – those are design specifications that describe what you’re building and how it breaks down. If you have an overall range target for the R1T, how does that break down into battery capacity? Into specific cells? It becomes a schema for how these companies design.

Five years ago, requirements were hard mandates that went into a Gantt chart and never changed. In a modern company, they change almost daily. You learn: “I tried that battery pack, but heat dissipation was faster than expected, so I need to switch, which changes battery capacity, which changes the design envelope, which affects the centre of gravity, which impacts other teams.” Each impact cascades.

So Flow is, at its core, the schema for how these companies collaborate in a cross-functional, iterative way. We started with requirements management, then moved to testing and architecture. But what we want Flow to be is a single source of truth for a system: the place engineers open in the morning.

On the AI side: if you look at how quickly AI has changed software development, it’s extraordinary. A couple of years ago people called it “a dumb intern.” It’s now pretty clear that by the end of this year, at least in Silicon Valley, AI will be writing the vast majority of software. The TAM for software engineering is around $2 trillion globally, and that’s moving from people writing code to people with AI doing the execution work.

Physical engineering is actually a larger market. I built Flow because I didn’t want to be a CAD monkey, an Excel monkey, or a simulation monkey. A couple of years from now, all of that execution work will be done by agents, and people will move from doing execution work to managing an army of agents.

If you have a thousand people at Rivian using Flow daily, each of them needs to work cross-functionally. So they won’t have one agent – they’ll have a mechanical agent, an electrical agent, a systems agent, a test agent, a regulatory agent. Thousands of people, five to ten agents each, we’re talking about tens of thousands of agents. The orchestration problem is extremely difficult. So what Flow is evolving into is: from an orchestration layer for humans collaborating on systems, to an orchestration layer for AI.

Our strong belief is that within 12 months, the vast majority of physical engineering work will be automated by AI, enabling teams to move massively faster and design massively more complex products than before.

Carlos: With all that, there’s a challenge in communicating it to both leadership and the teams using your product. Go-to-market is typically one of the hardest things for an early-stage company. Walk us through how that has shifted – from early days to now.

Pari: We’ve learned a huge amount here, and there’s been a lot of iteration.

When I started Flow as a software company, the goal was always to be bottoms-up, PLG. That’s how I use software. That’s how the best companies grow. We said, “We’ll just take that playbook and apply it to the physical engineering world.” And that didn’t work.

We were really confused by the fact that it didn’t work… until we understood why. Your SDR doesn’t get to pick your CRM. The VP of Sales picks the CRM because it reflects how the organisation works. SAP is a company-level decision. We were playing the wrong game. We thought we were in a tools game. We realised that we were in a cultural transformation game. We don’t sell a tool. We sell a way of working.

That was the big unlock, and it had lots of downstream consequences: on who we sell to, how we sell. I go to Chief Engineers, VP Engineerings, and CTOs of incredibly successful organisations I look up to, and I tell them they can do better and suggest how to work. That was a strange thing to get our heads around, but it’s what made go-to-market work.

Carlos: So you probably have a pretty good view on what separates elite engineering teams from average ones?

Pari: The single most important differentiator is always speed. Always, always, always. A few fun stories.

We were selling Flow to three different launch companies simultaneously:one in Europe, one early-stage in the US, and one of the most elite launch companies in the world.

The European company said: “It’s February, we love Flow, this will completely transform the company. Next week’s bad. The week after’s bad. Then we’re into half-term, then we’ve got a sprint, then it’s summer… so we’d love to book a meeting urgently for September.” Jesus fucking Christ.

The US seed-stage company said: “This is amazing, this is the future, we need it today. Let’s sign a pilot. We’re not going to overthink it – here’s some money.” We went from first meeting to signed pilot in three weeks.

The elite organisation – a much larger company – went from first meeting to Flow being deployed and stood up in four and a half weeks. They said: “We’re going to do this. If it doesn’t work, we’ll rip it out, no harm, no foul.” Making a decision in four and a half weeks and being willing to rip it out if it didn’t work was the fastest path to learning. A year and a half later, we’ve grown from 10 users to 270 users at that company, and Flow is now being used to design some of their most important vehicles.

Rivian is another great example. They went to market evaluating requirements tools – the system of record, one of the most important pieces of infrastructure they’d work with. They demoed 30 organisations, narrowed to five trials in three weeks. They told us: “Flow’s a bit early for us, but we love the product and want to give you a shot. The one thing we need to know is that you’re a real long-term partner. If you have downtime, we can’t ship cars.” We started at 40 users. Within four months, they grew to over a thousand users. Today, Rivian has over a million requirements in Flow, a million test cases, and they hit the API 95,000 times every night. The scale of design and testing running through just one customer is extraordinary. And the pattern is consistent across our best customers: they don’t overthink it. They buy, they roll out, and if it’s a bad idea they rip it out.

Carlos: Where do most engineering teams lose time without realising it?

Pari: There is always an instinct, as an engineer, to do a little bit more thinking, a little bit more de-risking. What we’ve learned is that a culture of aggressive design-build-test loops will win, even with some failures along the way.

If you’re designing a BMS for an EV and you say, “Taking an extra week, I can make sure this iteration is right’, that leads you down one path. But if you build an engineering culture where you can ship a new BMS every three weeks, continuously, it doesn’t matter if you get it wrong the first two or three times. You know there’s another iteration in three weeks, and you carry the learnings forward.

The meta game is: how do I build a culture of extremely fast iteration? That reduces the risk of any one iteration and builds a culture of continuous learning.

Carlos: What are the structural issues that slow down teams more than technical complexity?

Pari: Siloed working.

You’ve got four teams – mechanical, electrical, software, regulatory – each with 50 to 100 engineers, each working in different tools. Software in GitHub, making changes daily. Mechanical in Excel and CAD. Electrical in another tool. Regulatory in another. Tiny changes in one team will affect the others, and understanding exactly where those gaps are is very difficult.

That’s the single biggest problem: one system, fragmented across teams and tools. And there’s a decision to be made around meetings. Too many meetings and you get misalignment down to zero, but you don’t ship anything. No meetings and you blow up the vehicle. The balance is building a culture of continuous communication — not too many meetings, but enough that people can rapidly flag misalignments and iterate.

Carlos: Can I extrapolate that the AI feature set will come in really handy in striking that balance?

Pari: Absolutely. These are incredibly smart people who love engineering and want to spend their time on trade-offs, architecture, and systems design. What they actually spend their time on is: “This person is using the wrong number, I’ll go talk to him. He tells me there’s another misalignment,I’ll go talk to her.” They become rote communication agents inside the organisation.

In software engineering, the core problem is how do we build the right code as quickly as possible. In physical engineering, the single biggest problem is orchestration. Each component of a plane – the wing, structures, valves, piping, electronics – has been designed millions of times before. The hard part is bringing those components together and managing the cascade of changes when one part is modified. The problem is orchestration and continuous integration, and we believe the vast majority of that work is extremely automatable.

Carlos: How big is your team now?

Pari: About 20 people.

Carlos: You’re still in that happy zone.

Pari: I have a very strong mandate to keep the team as small as humanly possible. When we raised our Series A, we had already closed some of the most important space, nuclear, robotics, and automotive companies in the world. We had thousands of daily active users, we were incredibly profitable – and we did it all with eight people.

The core belief is: we want to be the SAS, not the army. Ultra-small, ultra-elite teams that can rapidly change direction and do multiple things together. We never want to be a rank-and-file army.

When we were closing Rivian, the company we were ripping out – their requirements tool vendor – had a go-to-market team two to three times the size of our entire business.

Carlos: You cannot use that answer for the next question.

Pari: Hit me.

Carlos: What belief about building companies has changed the most for you since founding Flow?

Pari: When I started the company, I was 21 with no real-world experience. I could write the software, do the mechanical and electrical engineering, run the CFD models, do sales, do fundraising. So I said: just hire a bunch of smart 21-year-old mechanical engineers and put them in every function. That’s what I did: me and 10 other mechanical engineers from Imperial College, covering every domain.

Phase one: I thought IQ was the only thing that mattered. That didn’t work.

Phase two: I thought it was experience. I hired people with the best marketing experience, the best sales experience, the best product design experience. That didn’t work either.

What I learned is that the single most important characteristic – whether someone will succeed at Flow – is hunger. Does this person want to win? Are they willing to do whatever it takes? Late nights, evenings, redoing their work, grinding, getting on a plane?

“Get on a plane” is actually one of our core values. You don’t overthink it. You get on the plane, go talk to the customer or the engineer, get to where the problem is, and go solve it.

Now I look for hunger above everything else. Then IQ. But hunger, motivation, and drive is still the single most important thing you need in a company.

Carlos: Lightning round. Most overrated engineering metric?

Pari: Low-level KPIs. Almost completely useless. You need one or two high-level guiding lights. Gut feel is always better than logic. You can logic your way into anything, but gut feel is usually where the right decisions live.

Carlos: Most underrated engineering habit?

Pari: Talking to users. I know it’s obvious, but you’d be shocked how infrequently it actually happens.

Carlos: One tool you use the most, if I did a screen-time analysis on your phone?

Pari: Pen and paper.

Carlos: Really?

Pari: Apple Pencil and a little iPad. A lot of my job isn’t to work in the business – it’s to know where the business needs to be in a year, and then get the company there. I go from being very locked in – solving a sales deal, a product problem, an engineering issue – to completely checking out and going for long walks, thinking about what the future looks like and how we get there. A lot of that thinking happens on pen and paper. I still haven’t found anything better.

Carlos: Is that something you picked up during the Flow journey, or has it always been with you?

Pari: I’m an engineer. I came up on pen and paper. It was how I learned, how I thought, how I visualised ideas. It’s always been true for me.

Carlos: Well, thank you so much, Pari. This has been an amazing conversation. We could go into much more detail across so many threads. I love watching the story evolve, and we’re only touching the beginning of the hardware revolution. This is going to be an amazing decade for you.