Here is a slightly uncomfortable fact about building complicated physical things - rockets, electric trucks, air taxis, fusion machines. The hard part is often not the physics. The physics is genuinely hard, but the physics is what the engineers signed up for. The part that quietly eats programs alive is the bookkeeping: keeping a few thousand people agreeing on what the thing is supposed to do, as the thing changes, every day, for years.
That bookkeeping has a name in the trade. It is called requirements management, and for a long time it lived in two places: enormous, expensive enterprise tools with names like DOORS, and enormous, cheap spreadsheets that everyone actually used because the enterprise tools took six to twelve months to roll out. Requirements are the well-defined needs a product must fulfill. Change one - move a bolt spec, revise a thermal margin - and you are supposed to trace every downstream thing it touches. In practice, someone with a whiteboard and a bad feeling does that. Sometimes they miss.
A tool built to survive a job
Flow Engineering did not begin as a requirements company. It began, in 2016, as a consultancy that designed hybrid rocket engines, under the less catchy name The Engineering Company. To do that work, its founder built an internal tool that wired together requirements, MATLAB models, CAD, and simulations so they all updated one another. The tool was good enough that work which normally took twelve weeks took about two and a half hours.
This is the oldest pattern in software: the internal tool you build to survive your own job turns out to be the actual product. By 2019 the company pivoted from consulting to building the software, and eventually rebranded to Flow. It formally became Flow Engineering in 2023 and opened a private beta that February. The founder, Pari Singh, is a mechanical engineer who studied at Imperial College London, worked on hybrid rocket engines as an undergrad, and then spent time at BAE Systems and BP - which is to say, he watched billion-dollar programs get coordinated over spreadsheets, and did not accept it.
Requirements, but alive
The Flow pitch, stripped of adjectives, is this: requirements should not be a rigid document that rots the moment it is written. They should be, in the company's own phrase, a "living, breathing nervous system." Technically, that nervous system is a connected graph - Flow calls it the systems graph - linking requirements to CAD, code, simulations, tests, and certification artifacts. Change something, and the graph knows what else just moved.
On top of the graph sit the things that make 2026 sound like 2026: an AI co-pilot you can ask about the state of a system, and custom agents that run repeatable engineering workflows and impact analysis. There is git-style branching and merging for proposed changes, which is a very software idea imported into a world that mostly did not have it. And there are integrations with the tools engineers already live in - GitHub, Jira, Slack, Confluence, Excel, and the big CAD and simulation packages.
The company reports the kind of numbers you would want if you were selling this: a 79% reduction in time spent maintaining requirements, roughly triple the test coverage, and a platform managing more than 100 million requirements across thousands of engineers. Take vendor metrics with the usual caution. But the direction is the point.
Who is actually using it
The customer list is a decent proxy for whether a hard-tech tool is real, because these buyers are unsentimental. Rivian is the headline: it designs the R1, R2, R3 and future programs in Flow, uniting somewhere around 1,500 engineers - battery, drivetrain, controls, body - in a single live system of record. It reportedly scaled from about 40 users to 1,500 in roughly four months, which is either a great sign or a stress test, and probably both.
Beyond Rivian there is a roster of the new hardware guard: Joby Aviation in eVTOL, Astranis and Stoke Space and Impulse Space in orbit, Figure in robotics, Xcimer Energy in fusion. What they share is not an industry - it is complexity, the tightly coupled tangle of mechanical, electrical, thermal, and software systems that no spreadsheet was built to hold.
The money, and the discipline
Flow raised an $8.5 million seed led by EQT Ventures in late 2022. Then, in October 2025, it raised a $23 million Series A led by Sequoia Capital, with participation from Stripe's Patrick and John Collison, Unity's David Helgason, ex-Figma leader Kyle Parrish, and Odyssey's Alastair Mitchell. Sequoia's Roelof Botha joined the board; the Collison brothers came on as advisors. Total funding sits around $31.5 million.
The detail worth pausing on is the order of operations. Flow reached profitability with a seven-person team before it took the big round. In hard tech, where capital usually goes toward covering a long, expensive climb, building a real business first and raising second is the unusual move. It means the money buys acceleration rather than survival - the company is now planning to grow headcount aggressively from a base of roughly two to three dozen people.
The OpenAI angle
In early 2026 Flow said it was collaborating with OpenAI on models tuned for engineering workflows, with early access to pre-release models. It is easy to be cynical about "partnership with OpenAI" as a press-release genre, so here is the substantive version: Flow's entire architecture is a structured graph of an engineering program, which is exactly the kind of well-organized context that frontier models are hungry for. A general model can write you a function. A model pointed at a systems graph can, in principle, reason about whether changing a requirement violates a downstream test - because the relationships are explicit, not buried in prose. Whether that reasoning is reliable enough to trust on a flight-critical system is the open question, and it is the right one to keep asking.
The company also talks about a future where you describe what a machine must do and the system helps generate the design - CAD produced from requirements, expansion from systems engineering into mechanical, electrical and simulation work. That is a long road. But it explains why Flow started with requirements specifically: own the layer that defines intent, and every other layer becomes something you can eventually connect to it, or automate against it.
Talent density over credentials
Culturally, Flow describes itself in the language a lot of ambitious small companies use - "extreme talent density," a preference for ambition and learning velocity over traditional credentials, an appetite for non-linear career paths. Ordinarily this is the part of a company profile you can safely skim. It is slightly more credible here for a boring reason: a team that got to profitability with seven people did not have room for passengers. The hires are coming from places like Applied Intuition, Anduril and Archer - companies whose engineers have felt the exact pain Flow is selling against, which is a useful filter. The plan from here is to grow that team several times over, which is where discipline tends to get tested.
The bet, and the ceiling
Flow's stated long-term goal is to "drive the cost of hardware design toward zero" - the sort of line that is either a mission or a mood board, depending on execution. The nearer-term story is more grounded and more interesting: software went from waterfall to agile decades ago, and hardware, the argument goes, is finally ready to make the same jump, with AI agents doing the continuous alignment that humans cannot.
The risks are honest ones. Incumbents like IBM DOORS, Jama Connect, Siemens Polarion and PTC's Codebeamer are entrenched, and regulated industries move slowly by design. Keeping integrations working across a shifting landscape of CAD and simulation tools is unglamorous, permanent labor. But if the thesis holds - that the highest-leverage document in engineering has been treated as an afterthought - then owning it, and connecting everything else to it, is a very good place to stand.
It helps that the competition is, in a sense, doing Flow a favor. DOORS traces its lineage to the early 1990s; Jama and Polarion to the 2000s. These are capable, deeply installed systems, and their installed base is precisely the problem - they were designed for a world of sequential, document-driven development, and their customers have a decade of process built around that assumption. That entrenchment is a moat against startups and an anchor against change. Flow's wager is that the newest hardware companies, the ones without twenty years of legacy workflow to protect, will simply start somewhere different. Newer entrants like Trace.Space and Valispace are chasing the same opening, so Flow is not alone in noticing it. The question is who becomes the default for the next generation of builders - and defaults, once set, are sticky. Requirements tools have high switching costs, embedded integrations, and a quiet network effect: engineers carry the tools they like from one company to the next.