The Second Wave of New Space Maturity: Engineering Rigor Catches Up

There is a specific kind of organizational pain that hits fast-moving aerospace companies around their fifth or sixth year of operation. The prototype mindset that got them to orbit—or close to it—starts generating real costs. A requirements change that would have taken a Slack message now takes three weeks to trace through six spreadsheets. A government proposal reviewer asks for a Systems Engineering Management Plan and gets back something that was clearly written in a weekend. A launch anomaly triggers a root cause process and the team realizes they cannot definitively answer which version of the flight software was on that vehicle.

This is the second wave of new space. The first wave was audacious and necessary: SpaceX, Planet, RocketLab, Relativity, Astra, and dozens of others proved that commercial space companies could move faster and cheaper than traditional primes by discarding what looked like aerospace bureaucracy. Some of that bureaucracy deserved to be discarded. A lot of it did not.

The companies that survived the first wave are now confronting that distinction at operational scale.

What the Prototype Mindset Actually Looks Like in Practice

To understand why the transition is painful, you have to understand what “scrappy” engineering looks like in a real new space company—not the idealized version, but the operational reality.

Requirements live in Confluence pages, Google Docs, or Notion, organized by whoever had the clearest head during the last sprint. There is typically one engineer who knows where the real requirements are and what they actually mean. When that person leaves—and in new space, that person always eventually leaves—the institutional knowledge leaves with them.

Configuration management is informal. Engineers check code into Git with reasonable discipline, but hardware configurations are tracked in spreadsheets that are one fat-finger away from a costly mistake. As-built records exist, sort of. Interface control documents are updated reactively, after the fact, when someone realizes two subsystems disagree about a voltage rail or a data format.

Verification is iterative and empirical. The underlying philosophy is: build it, test it, fly it, learn from the anomaly. This works extraordinarily well when the flight rate is high and the stakes per mission are bounded. It works less well when the payload is a crewed vehicle, when the constellation has 300 satellites requiring consistent behavior, or when a government customer needs to sign an Independent Technical Assessment.

None of this was irrational. For companies trying to get to first flight in 24 months with 40 engineers, formal systems engineering would have been paralyzing. The bet was: get to orbit fast, learn from real data, iterate. The companies that made that bet and survived it are now worth something. Now they have to build the engineering infrastructure that converts that survival into sustainable operations.

What’s Actually Forcing the Change

Three forcing functions are driving the maturity transition simultaneously, and they are hitting at different speeds and intensities.

Operational constellations demand configuration discipline. When you have 300 satellites in orbit with different hardware revisions, different software versions, and different operational histories, the question “what is actually up there?” becomes mission-critical. Anomaly isolation, predictive maintenance, and software upgrade planning all require accurate configuration state. Companies that ran their first 10-satellite constellations on spreadsheets are discovering, painfully, that this does not scale to 300. The problem is not just volume—it is the combinatorial complexity of hardware variants, software versions, and operational modes interacting across a fleet.

Government contracts introduce external compliance regimes. The transition from commercial-only to government-plus-commercial is where the engineering process debt becomes visible and expensive. Defense contracts invoke MIL-STD-882 for system safety. NASA programs reference NPR 7150.2 for software engineering. Launch services agreements bring range safety requirements with specific V&V obligations. These standards do not care that your culture values moving fast. They require traceable evidence that requirements were defined, allocated, verified, and validated—and that the evidence is auditable.

A company that built its first constellation on informal practices can still win government business, but the proposal reviewers will notice the gap, and the program office will require a corrective action plan before contract award. That plan has to be credible, which means it has to be funded and staffed.

Crewed systems are a different category entirely. Several new space companies are now in the crewed system development pipeline, whether as launch providers, habitat developers, or life support system suppliers. The regulatory and ethical stakes of crewed spaceflight demand a level of rigor that is genuinely different in kind, not just degree. Safety cases have to be built from requirements downward. Hazard analysis has to be traceable to requirements. Every deviation from a requirement has to be dispositioned and approved. The informal practices that built the uncrewed vehicle are legally and ethically insufficient for the crewed one.

The Organizational Changes That Actually Work

Companies that successfully navigate this transition tend to make similar organizational moves, and the sequencing matters.

Hiring a VP of Systems Engineering before the cultural work is done is usually a mistake. The organizational immune system will reject the new rigor if it arrives as a mandate from a new executive rather than as something the existing team understands they need. The most successful transitions begin with one or two experienced systems engineers embedded in program teams—people who can demonstrate that good requirements discipline actually makes engineering faster, not slower, by reducing rework.

The program management function has to level up alongside systems engineering. In a startup, program management often means someone who keeps the schedule visible and unblocks engineers. In a mature engineering organization running government contracts, program management means earned value management, integrated baseline reviews, and configuration control boards. These are learnable skills, but they require investment in training and tooling, not just hiring.

Quality assurance has to transition from “test everything at the end” to “build quality in from requirements.” This is partly a staffing question—quality engineers who understand requirements-based V&V are different from quality engineers who run acceptance test procedures—and partly a process question. The process has to define what it means for a requirement to be verified before anyone starts building hardware, not after.

Configuration management needs a dedicated function with actual authority. Configuration control boards that can say no—and that have the organizational standing to make that stick—are not optional for a company running an operational constellation. The CCB chairperson needs to be someone senior enough that engineers cannot simply route around the process when it is inconvenient.

The Tooling Investment Gap

The tooling reality in most new space companies is a patchwork that reflects the startup era: Jira for issues, Confluence or Notion for documentation, Git for code, a custom spreadsheet for the requirements traceability matrix, and a shared drive full of PowerPoint decks that represent the de facto design record.

This patchwork breaks at scale for specific, predictable reasons. Spreadsheet-based RTMs cannot maintain bidirectional links between requirements and verification evidence. Wiki-based requirement repositories cannot enforce change control or produce audit-ready change histories. Issue trackers are not requirements management systems, even when they are used as one.

The traditional answer to this problem was to install one of the established requirements management platforms: IBM DOORS or DOORS Next, Jama Connect, Polarion, or Codebeamer. These are serious tools with genuine capabilities. DOORS, in particular, has decades of flight heritage and remains the baseline for many defense aerospace programs. Jama Connect has strong review and collaboration workflows. Polarion integrates requirements and ALM in ways that make sense for large, complex programs.

The problem for new space companies is that these platforms were designed for and by traditional aerospace primes. Their information models are document-centric. Their deployment models are often on-premises or heavily IT-managed. Their learning curves are steep enough that full adoption requires dedicated tool administrators. And their cost structures, both in licensing and in implementation services, are calibrated for organizations with hundreds of systems engineers, not companies trying to scale from 15 to 60 SE practitioners.

There is a real and underserved gap between “spreadsheets that are failing us” and “full IBM DOORS deployment with a six-month implementation engagement.”

How Modern Tooling Is Closing That Gap

The more relevant question for new space companies in 2026 is not which legacy platform to adopt, but whether a newer generation of tools can close the maturity gap without the overhead of a legacy implementation.

The meaningful architectural difference in modern requirements platforms is the shift from document-centric to graph-based information models. In a document-centric tool, requirements live in hierarchical documents with manual link management between them. In a graph-based tool, requirements are nodes in a connected model, and relationships—derivation, allocation, verification, interface—are first-class objects that can be queried, analyzed, and maintained automatically.

This matters operationally because constellation-scale complexity is a graph problem, not a document problem. Understanding how a change to a top-level mission requirement propagates through subsystem allocations, interface definitions, and verification cases requires traversing a connected graph, not hunting through linked documents.

Flow Engineering (flowengineering.com) is an example of a platform built on this graph-based model, designed specifically for hardware and systems engineering teams. Its approach to requirements management centers on the relationships between requirements rather than the documents that contain them—which makes it structurally better suited for the kind of multi-level allocation and traceability that constellation programs require. For companies coming out of the startup era with fragmented requirement artifacts across multiple tools, Flow Engineering’s AI-assisted ingestion and relationship extraction can meaningfully accelerate the consolidation work that is otherwise a multi-month manual effort.

The AI-native distinction matters here in a specific way. The practical bottleneck in maturity transitions is not that engineers do not understand systems engineering—most do, at least conceptually. The bottleneck is that the cleanup work—normalizing legacy requirements, identifying gaps and duplicates, constructing the initial traceability graph—is tedious enough that it gets deferred indefinitely. Tools that automate the tedious parts lower the activation energy for doing the work.

What the Transition Actually Costs

Honest accounting matters here, because the costs are real and frequently underestimated.

Labor cost: A genuine systems engineering buildup for a company at the 150-200 engineer stage, running multiple programs including a government contract, requires somewhere between 15 and 25 dedicated systems engineers—not including the configuration management, quality, and program management functions. In 2026, experienced systems engineers in aerospace are expensive and scarce. Budget accordingly.

Rework cost: Retrofitting requirements traceability onto a design that was built without it is always more expensive than building it in. The earlier a company starts the transition, the lower this cost. Companies that wait until a government program office requires a corrective action plan are paying the highest possible price.

Cultural cost: This is the most underestimated cost. Engineers who built their careers on the prototype mindset do not always welcome the discipline that maturity requires. Some will leave. Some will adapt. The companies that manage this transition well invest heavily in explaining why the rigor exists and what it enables—not just mandating compliance.

Tooling cost: A modern requirements management platform is not free, but it is also not the seven-figure implementation engagement that a full legacy DOORS deployment can become. The real cost is adoption—getting engineers to use the tool as part of their actual workflow rather than as a compliance checkbox.

Honest Assessment

The new space companies that are navigating this transition well are not abandoning what made them fast. They are making selective, deliberate investments in rigor for the parts of the program where rigor pays off: requirements management, configuration control, and V&V planning. They are keeping iteration speed where it belongs: in the manufacturing process, in the software deployment pipeline, in the operational response to anomalies.

The companies that will struggle are the ones that treat maturity as a bureaucratic tax rather than an engineering capability. They will hire the director, install the tool, write the plan—and then route around all of it when schedule pressure arrives, because the culture never actually changed.

The engineering discipline that traditional primes built over decades was not all overhead. Some of it was genuine learning about how complex systems fail. The new space companies that survive the second wave will be the ones that can absorb that learning fast enough to stay competitive, without losing the speed advantage that made them worth paying attention to in the first place.

That is a hard balance. The companies that find it will define what mature new space engineering looks like for the next decade.