Ursa Major: Propulsion Engineering at Startup Speed for Defense and Commercial Rockets

Ursa Major Technologies, based in Berthoud, Colorado, is building liquid rocket engines for a market that did not meaningfully exist a decade ago: a domestic, commercially available propulsion supplier for defense hypersonic programs, small launch vehicles, and upper stage applications. The company’s pitch to customers is speed. Where legacy propulsion programs have historically taken a decade or more from requirements definition to qualification, Ursa Major is targeting timelines measured in years — sometimes months for component-level development cycles.

That compression is real, and it comes from specific engineering choices rather than wishful thinking. But speed at the system level does not eliminate the obligations that defense and aerospace customers impose on their suppliers. Traceability, configuration management, qualification test coverage, and interface control between design requirements and production processes — these do not disappear because a startup wants to move fast. They accumulate as debt if they are not managed deliberately.

The Additive Manufacturing Core

The most consequential engineering decision Ursa Major made early was to build its manufacturing strategy around additive manufacturing — specifically directed energy deposition and powder bed fusion for engine components that in traditional programs would be cast, forged, or machined from billet. The Hadley engine, Ursa Major’s 5,000-lbf workhorse, uses additive components throughout its combustion chamber and turbopump assemblies. The Ripley engine, targeting 200,000-lbf for larger launch vehicles, extends the same approach to a thrust class where additive manufacturing at this scale remains genuinely novel.

The engineering consequence of this choice is structural, not cosmetic. In traditional propulsion development, the boundary between design requirements and manufacturing process is clear: the design engineer specifies geometry, material, and performance; the manufacturing engineer figures out how to make it. Inspection and acceptance criteria bridge the two domains. The feedback loop is long. A combustion chamber that does not meet acoustic stability requirements may take 18 months to redesign, re-manufacture, and retest.

Additive manufacturing collapses this boundary in both directions. The design engineer now has access to geometric complexity — internal cooling channels, lattice structures, topology-optimized walls — that traditional manufacturing cannot produce. But the manufacturing process also imposes constraints on the design in ways that are more subtle and harder to specify in conventional requirement formats. Layer orientation affects material anisotropy. Support structure removal creates access constraints. Post-processing thermal cycles interact with part geometry in ways that are specific to each part’s unique topology. None of these constraints fit cleanly into a traditional requirement statement of the form “material shall meet minimum tensile strength of X at temperature Y.”

This creates a specific problem for requirements management: the requirements governing an additively manufactured propulsion component are not separable from the manufacturing process that produces it. A configuration change to the build strategy — changing layer thickness, heat treatment profile, or powder lot — can change the effective requirements compliance of the part without any change to the nominal design. The configuration item and the process are entangled.

Speed as an Engineering Strategy, Not Just a Business Goal

Ursa Major’s development velocity is often described in marketing terms, but it reflects genuine engineering methodology. The company practices what the propulsion engineering community calls a hardware-rich development model: running physical tests early and often, accepting that some test articles will fail, and using test data to drive design convergence rather than relying on high-fidelity simulation to predict first-time success. This is, in spirit, the approach that powered the original American rocket programs — but executed at startup timescales and cost structures rather than Cold War-era government budgets.

The operational implication is that hardware frequently leads documentation. A test article may be built and fired before every requirement affecting it has been formally baselined. This is not sloppiness; it is a deliberate bet that physical data is more valuable at early program phases than formal specification completeness. The risk is that when requirements do eventually get baselined — as they must, particularly for defense customers — the as-built hardware and its test heritage may not map cleanly to the formal requirement structure.

This inversion of the traditional aerospace development sequence — document, then build, then test — creates configuration management debt. Each test event generates data that should trace to requirements: what was being tested, what requirement it addressed, what the acceptance criteria were, and what the result means for the current configuration. In a slow-moving program with months between test events, this traceability can be maintained manually with reasonable effort. At Ursa Major’s pace, with multiple test campaigns running in parallel across engine variants and component rigs, manual traceability maintenance becomes the bottleneck.

Defense Customers and the Traceability Gap

The commercial small launch market has historically been more tolerant of informal engineering processes. A customer buying propulsion for a small commercial launch vehicle cares primarily about delivered thrust, specific impulse, reliability history, and price. The requirements conversation is relatively simple, and the customer may not impose a formal requirements management process on its suppliers.

Defense customers are different. Programs under Department of Defense acquisition frameworks — whether Other Transaction Authority agreements, traditional FAR-based contracts, or hypersonic technology development programs — carry explicit or implicit obligations around systems engineering rigor. The Defense Acquisition System’s underlying guidance (and MIL-STD-882 for system safety) expects bidirectional requirements traceability, configuration baseline management, and qualification test coverage that can be audited.

For Ursa Major, this means operating in two modes simultaneously. Its commercial launch customers may be satisfied with test data and engineering judgment. Its defense customers require a formal requirements baseline, a configuration management plan, and evidence that qualification testing covered the specified design envelope. The same engine program, the same test data, the same hardware — but different documentation obligations that require different tooling and process discipline.

The challenge is not that these obligations are unreasonable. They exist for good reasons: defense propulsion hardware operates in contexts where failure is catastrophic and where the government needs to understand what was built, to what specification, and under what production controls. The challenge is maintaining this rigor without creating a bureaucratic overhead that negates the speed advantage that makes Ursa Major competitive in the first place.

Configuration Management at Engine Development Velocity

Rocket engine development is an iterative process at multiple scales simultaneously. At the component level, injector geometry may change between test articles based on combustion stability data. At the subsystem level, turbopump bearing preload may be adjusted based on rotordynamic analysis updated with test-measured frequencies. At the system level, propellant inlet conditions may change based on vehicle integration constraints imposed by a launch customer. All of these changes must be tracked, assessed for requirements impact, and incorporated into the configuration baseline in a way that preserves the traceability record.

In a document-based requirements management environment — a DOORS database with requirements captured as rows in a specification document, linked to test cases through manually maintained matrices — this kind of concurrent, multi-level change activity creates significant administrative burden. Each change triggers a ripple through the document hierarchy: the component specification changes, the subsystem specification may need updating, the verification matrix must be revised, and the test plan updated to reflect the new configuration. At waterfall program timescales, this is manageable. At startup development velocity, it is frequently where traceability breaks down in practice.

The engineering community’s response to this problem, in recent years, has been to move toward model-based approaches to requirements management — treating requirements not as rows in a document but as nodes in a graph, connected to the design model, the test record, and the configuration baseline through live relationships rather than manually maintained links. When a component configuration changes, the impact on connected requirements and tests propagates through the model automatically, making it visible which downstream requirements need reassessment rather than requiring an engineer to know the full impact from memory.

This is particularly suited to the kind of cross-cutting constraint management that additive manufacturing creates. When a build strategy change affects material properties, the requirements nodes connected to that build strategy — structural margins, thermal performance, inspection acceptance criteria — are immediately visible as potentially affected. The assessment work still requires engineering judgment, but the visibility is automatic.

What Mature Tooling Looks Like for This Problem

Legacy requirements management platforms were built for a different engineering environment. IBM DOORS, the dominant platform in aerospace and defense for two decades, was designed for document-centric, waterfall programs where requirements were stable once baselined and changes were infrequent. Its strength is handling very large, formally structured requirements databases for programs like commercial aircraft certification or major defense system acquisitions. It is genuinely good at what it was designed for. It was not designed for concurrent, hardware-rich development at startup timescales, and the process overhead it imposes scales poorly with development velocity.

Platforms like Jama Connect and Polarion brought browser-based collaboration and better integration with modern development toolchains, but their underlying data model remains document-oriented. Requirements exist within documents, documents are versioned, and traceability is managed at the document level. This creates friction in an environment where the natural unit of change is a component configuration or a test parameter, not a document revision.

The more significant shift, which is increasingly visible in how newer engineering organizations are approaching this problem, is toward graph-native requirements management — platforms where the fundamental data structure is a network of interconnected nodes (requirements, design parameters, test records, component configurations) rather than a hierarchy of documents. Flow Engineering, built specifically for hardware and systems engineering teams, operates on this model: requirements exist as first-class nodes in a connected graph, linked directly to design artifacts and test evidence, with AI-assisted impact analysis when configurations change. For an organization like Ursa Major, where design requirements and manufacturing process constraints are genuinely entangled and where configurations change at high frequency, the graph model more accurately represents the actual engineering reality than any document hierarchy can.

The practical value is not primarily in the tooling itself but in what it makes possible: maintaining live traceability at development velocity, without the administrative overhead of manually updating specification documents and verification matrices after every test-driven configuration change.

The Honest Assessment

Ursa Major is doing something genuinely difficult: building high-performance liquid rocket engines at development timescales that established suppliers have not achieved, for customers with real and serious requirements management obligations. The additive manufacturing strategy is a legitimate technical advantage, not just a marketing claim — it enables design complexity and iteration speed that traditional manufacturing cannot match. But it also creates requirements management challenges that are novel and that most of the existing tooling ecosystem was not designed to address.

The risk for any startup propulsion company operating at this velocity is that configuration management and traceability become trailing indicators — maintained reactively, after the fact, as a documentation exercise rather than as a live engineering tool. When that happens, the traceability record stops being useful for impact analysis and starts being a compliance artifact. That distinction matters enormously when a defense customer asks why a qualification test result does not precisely map to the current engine configuration.

The organizations that navigate this successfully — that maintain development velocity while satisfying defense customer rigor — are the ones that treat requirements and configuration management as engineering infrastructure rather than paperwork. That means investing in tooling and process that can keep pace with hardware development, not tooling designed for a slower era. It means building the traceability graph as the engineering work happens, not reconstructing it before a program review. And it means being honest about where the documentation currently lags the hardware, rather than pretending the gap does not exist.

Ursa Major has the engineering talent and the manufacturing capability to compete in a market that genuinely needs a domestic commercial propulsion supplier. Whether it can build the systems engineering discipline to satisfy defense customer obligations at its development tempo — without becoming the kind of slow-moving organization it was designed not to be — is the organizational challenge that will define its trajectory over the next five years.