I met Flow’s founder, Pari Singh, at one of his investors’ offices (EQT), where we had a relatively fast shoot as most of the footage was to be sent from their UK based HQ — just an interview, BRoll of Pari at the computer, and a demo of Flow.

But boy did that demo impress me nonetheless.

When I think of the advanced engineering required for things like fighter jets, rockets, and race cars I’m imagining the cutting edge in everything. Cutting edge performance, parts, talent, and of course engineering methodology.

The reality is that most things are budget, time, and resource restrained. And very rarely is anything ever “cutting edge,” especially the software used to design these advanced machines.

An annoying variety of filing-cabinet-style, documentation-based, or ticketed systems are used together to create janky contraptions for companies doing cutting-edge engineering.

These software solutions are so bad that larger companies usually end up making their own such as SpaceX or even earlier on like Stoke has.

All in all, most software is adapted to preferred engineering methods of teams using them or built for that exact purpose — normally the traditional V model of engineering.

Flow wants to bring an entirely new paradigm to the way modern engineering is done. Its key features are as follows:

• Macro & micro views — from system level to component level view

• Dependencies linked & trackable — the ability to understand the context and needs of requirements

• Digital twin testing — the ability to digitally test different parameters interlinked with each other like scripts, CAD models, and physics simulations

• View modes — view work by engineer, team, milestone, contextually, or by system

My experience with Flow shocked me — how well the digital twin system worked despite the complexity of the project file and how overall smooth and fast it was amazed me.

What’s even more impressive and surprising is Flow’s origin story.

An amazing pivot

Today in Silicon Valley, conviction and vision are rarely recommended as the right thing for founders to do versus pivoting. Ship fast, talk to users, pivot — is key advice, especially in the world of software.

Flow ,however, started out not as a software company, but a rocket company.

Pari and his band of ex-F1, aerospace, and oil industry engineers wanted to build rocket engines.

“The only problem was that we were in the UK so there wasn’t any test equipment or capital interest,” Pari explained in the 7th episode of S³.

When they took their rocket engine design business to investors they apparently sat the team down and told them they had no clue what they built. The gist was something like: you’ve invented a new paradigm of engineering, you need to box it up and sell it as software.

They really didn’t want to do this — they loved the engineering they were doing with rockets, why would they want to do software?

When thinking on the two paths they could take Pari explained that they remembered what working in industry was like, “We all wanted to build things as fast as we could but the tools were too slow and limiting.”

That’s when they knew they needed to stop making rockets, and begin developing an entirely new way to do engineering with Flow.

Trojan horsing your product

The Flow team has a history of making things so good they either needed to lie about how long things took them or simplify their product to trick people into using it.

When they were “the rocket company,” they were able to create thousands of variant digital twin designs for rocket engines in hours.

Most competitors took 12 weeks to do this so when they told clients they could do it in hours they were met with skepticism — so they lied and said it took 2 weeks. This is still 1/6 of the next best design firm’s times, but it’s more than 14 times of the reality of how long it takes them!

After they pivoted to creating Flow and got the software working, they ran into a similar problem.

Upon demoing the power of their multi-API digital twin system that could quickly validate requirements and “flow down” parameter changes across advanced engineering systems, prospective customers thought it was amazing yet didn’t see how such a big difference in approach to software engineering could integrate into their way of doing things.

So, the Flow team did something brilliant and simplified their sales pitch, packing it as a “requirements” tool.

Sometimes sales isn’t about selling the best in class, but about selling a solution to a real problem — for hardware engineering requirements tracking is a real problem and a bigger headache.

From the UK for the US DoD

If you’ve ever worked with the DoD as a non-government entity you know how painful it can be as a US based company to follow all of their security thresholds and export controls — it’s compliance on hard mode.

Creating software as a non-US company for the private US DoD marketplace? That’s extremely hard mode.

Yet, Flow is well on the route to making this a reality.

With many customers in the US and their next milestone focused on integrating GovCloud into their platform they may be one of the few non-US companies to become deeply embedded in the future of US DoD manufacturing.

Today, Flow is already being used by cutting edge engineering teams across the world such as Space Machines, Universal Hydrogen, and Brinc. Their next big steps are further expanding into the US marketplace, meeting DoD compliance standards, and continuing to unlock engineering potential for teams working on cutting edge technology.

Thanks again Pari for making the time to film while you were in SF — I can’t wait to hear and share more success stories from the use of Flow.

Keep on building the future,

— Jason