Terran Orbital: Building Small Satellites at Scale and the Engineering Process That Makes It Possible

Terran Orbital occupies a specific and genuinely difficult position in the space industry: they are trying to do volume manufacturing of spacecraft, and spacecraft have never been designed with volume manufacturing in mind. The company builds small satellites — primarily in the 6U to 200kg class — for U.S. government customers, including a significant contract vehicle with the Space Development Agency, as well as commercial constellation operators. The technical challenge they face is not primarily about the satellites themselves. It is about the process of producing many of them, consistently, with controlled variation, at a cost structure that makes the business viable.

That engineering process challenge is worth examining in detail, because it is increasingly the challenge the entire smallsat industry faces as constellations get larger and government demand for proliferated low-Earth orbit architectures increases. How Terran Orbital approaches it reveals the genuine distance between traditional spacecraft engineering culture and what production-scale satellite manufacturing actually requires.

Production Rate as a Design Constraint

The most important shift in Terran Orbital’s engineering philosophy is treating production rate as a first-class design requirement. In traditional spacecraft development, production rate is a manufacturing concern — something the production team worries about after the engineers have finished designing the vehicle. The schedule pressure is real, but the design is treated as fixed before anyone asks how many units per month the factory needs to deliver.

At production volumes consistent with large government constellation contracts — where you may be delivering dozens of spacecraft per year — this sequencing breaks the program. Terran Orbital’s engineering approach inverts it: production rate targets drive design decisions from the beginning of the development cycle, in the same way that mass margin or power budget does.

What does that look like in practice? It means that when a subsystem engineer proposes a design, the evaluation criteria include assembly time, test time, and the number of touch-labor steps, not just performance and margin. A guidance, navigation, and control architecture that delivers slightly better pointing accuracy but requires manual calibration on each unit loses to a solution that delivers adequate pointing accuracy with a calibration process that can be automated and parallelized. “Adequate” is the operative word — the design goal is not maximizing performance, it is hitting required performance reliably across units while minimizing per-unit production cost.

This is a significant cultural shift for engineers trained in the heritage spacecraft world, where the dominant anxiety is always margin. At scale, the dominant anxiety shifts to variance. A subsystem that performs at 110% of requirement on one unit and 88% on the next creates a testing and disposition problem that, multiplied across a large production run, costs more schedule and money than the design saved by being clever.

The structural implication is module standardization. Terran Orbital has invested heavily in defining standard structural and electrical interfaces that constrain how subsystems connect to the bus. This reduces the design freedom of individual subsystem teams but dramatically simplifies final assembly integration. The bus does not care which vendor supplied the radio or the attitude control system, as long as both comply with the interface standard. That interoperability is what makes parallel supplier strategies and design evolution possible without rebuilding the assembly line.

Managing Configuration Across a Non-Identical Fleet

The second engineering challenge is configuration management, and it is harder than it sounds. Terran Orbital is not building identical units. Government customers may specify different payloads, different orbits may drive different thermal configurations, and component availability — especially for radiation-tolerant parts with constrained supply chains — means that material substitutions happen regularly during a production run. The fleet of delivered satellites is similar but not identical, and tracking exactly what is on every unit, permanently, is a foundational requirement for on-orbit operations and anomaly resolution.

Traditional spacecraft configuration management evolved for programs where you are tracking one or two vehicles over a decade-long development cycle. The tools and processes are oriented toward depth — exhaustive documentation of a single configuration baseline. When you are producing satellites at volume, you need breadth: the ability to track configuration state across fifty or a hundred units simultaneously, with clear visibility into which units carry which variant of which component, and what the engineering disposition was for any deviation from baseline.

This is a data architecture problem as much as a process problem. Maintaining this in document-based systems — spreadsheet-driven change logs, PDF-based test records tied to a serial number by a naming convention — becomes unworkable at scale. The fundamental issue is that document-based configuration management treats each unit’s history as a separate document to be assembled, rather than as a query against a connected data model. When an on-orbit anomaly occurs on unit 23 and the operations team needs to know whether units 17 through 31 share the same memory controller silicon revision, a document-based system requires a manual search across 15 separate unit folders. A connected model answers the query in seconds.

Terran Orbital’s production scale forces this architectural question into view. The configuration management system has to function as a live database of physical units, with traceability from requirements through design decisions through build records through test results through launch configuration. Any gap in that chain is a liability when an anomaly needs to be bounded across the fleet.

The practical approach to this problem involves several elements: a part numbering and revision control scheme rigorous enough to distinguish genuine functional differences from cosmetic part number changes; a deviation and waiver process that records not just approval but engineering rationale, so that a substitution made under schedule pressure in year one can be evaluated for risk in year three when a related anomaly appears; and test data retention at a level of fidelity that allows statistical comparison across units, not just pass/fail certification.

Supplier Qualification for Volume Production

Terran Orbital’s supplier qualification process reflects the same production-oriented logic. In traditional spacecraft procurement, supplier qualification focuses almost entirely on heritage and performance: has this component been used in space before, and does it meet the environmental and performance specification? Those are necessary questions, but for a volume producer they are not sufficient.

The additional questions are about yield, consistency, and supply chain stability. A radiation-tolerant processor that performs excellently and has strong flight heritage, but is produced in lot sizes of 50 units per year from a single source, is a program risk for a constellation builder. If that supplier has a yield excursion or a raw material supply disruption, it can halt an entire production line.

Terran Orbital’s qualification process therefore includes supply chain depth assessments — not just “is this part available” but “what is the production capacity, what is the typical lot-to-lot variation in key electrical parameters, and does the manufacturer’s process control maturity support consistent production over a multi-year program?” The last question is where the most due diligence is required, because small component suppliers that serve the heritage spacecraft market have often not been asked these questions before. Their quality systems are oriented toward producing a few hundred parts per year to a very high standard, not thousands of parts per year to a consistent standard. Those are different process control challenges.

The yield question matters in a specific way for smallsat volume production. When a test is destructive or the test itself consumes meaningful production time, testing every unit to the full qualification level is not economically viable at scale. The engineering response is to qualify the manufacturing process rigorously and then apply acceptance testing that verifies conformance to that process, rather than re-proving performance on every unit. This shifts risk from acceptance testing to process qualification — which means the supplier’s manufacturing process documentation and statistical process control data become first-order inputs to the qualification decision, not supporting evidence.

This approach is well understood in automotive and consumer electronics manufacturing. In the spacecraft industry, it represents a genuine cultural transition. The instinct of a spacecraft engineer is to test the hardware. The production engineer’s instinct is to control the process. At Terran Orbital’s scale, both instincts need to coexist, and the engineering process has to define explicitly where each applies.

The Test Philosophy Problem

Volume production also forces a rethinking of spacecraft test philosophy. The traditional spacecraft test approach — thermal-vacuum cycling to qualification levels, acoustic and vibration testing, full electromagnetic compatibility testing on every unit — was designed for a world where you are building one spacecraft and a proto-flight model. When you are building 50 units per year, you cannot run every unit through a full qualification-level environmental test sequence. The cost and cycle time would make the program unviable.

The industry response, which Terran Orbital employs, is acceptance-level environmental testing on production units, with more rigorous qualification testing on design verification units and periodic lot sampling. The engineering challenge is justifying the reduced test levels — demonstrating through analysis and statistical sampling that the acceptance test is genuinely sufficient to screen for workmanship defects, which is its purpose, without needing to re-demonstrate design margin on every unit.

This requires careful engineering analysis up front and disciplined anomaly tracking through the production run. If in-process test yields or on-orbit performance data begin to show trends, the response is to investigate the design or process, not simply to add more acceptance testing at the end. Downstream testing is expensive; fixing the upstream process is efficient.

What the Industry Can Learn

Terran Orbital’s engineering challenges are a preview of where the broader spacecraft industry is heading. As the Space Development Agency’s proliferated LEO architecture matures, as commercial constellation operators grow their fleets, and as launch costs continue to decline in ways that make large satellite numbers economically attractive, production-scale thinking will become a baseline competency for spacecraft manufacturers rather than a differentiating capability.

The shift requires more than acquiring new tools — though connected, model-based configuration management systems and production analytics platforms are real enabling technologies. It requires a change in what spacecraft engineers are trained to optimize for. Margin maximization, while still necessary, has to coexist with variance minimization, production cycle time, and process repeatability as first-class design objectives.

The gap between a team that can build one excellent satellite and a team that can build fifty adequate-but-consistent satellites is wider in aerospace than in almost any other manufacturing domain, because the heritage of the industry runs so strongly toward bespoke precision. Terran Orbital is working at that gap directly, and the engineering process decisions they are making — treating production rate as a design constraint, investing in fleet-wide configuration visibility, qualifying suppliers on process maturity rather than part heritage alone — represent a coherent answer to a problem the industry will not be able to avoid.

Whether Terran Orbital’s specific business outcomes validate those process investments remains a separate question from whether the investments themselves are directionally correct. As an engineering process matter, they are.