State of Satellite Production at Scale — Epsilon3 2026

Epsilon3 · Industry Report · 2026

// SATELLITE_PRODUCTION_SCALE · REV_1.0
Built by aerospace operators

State of Satellite Production

Production
at Scale

What it actually takes to go from first satellite to a hundred a year

The satellite manufacturing industry is at an inflection point. The engineering challenges that defined the last decade — propulsion, power, autonomy — are increasingly solved. The challenge that defines the next decade is operational: building the execution infrastructure that lets programs scale without breaking.

01 · 02 · 03

The Inflection Point · The Craft-to-Industrial Gap · Three Failure Modes

04 · 05

What Vertical Integration Actually Demands · The DoD Standard

06 · 07

How the Programs That Scaled Built · The 2026 Window

01 · The Inflection Point

The Market Has Changed.
The Operations Haven't.

The satellite manufacturing market is projected to grow from $21.8 billion in 2025 to $86.7 billion by 2035. SpaceX produces roughly five Starlink satellites per day. SDA Tranche 3 contractors are running production lines sized for 18 satellites in three years. The economics of building and operating satellites have been fundamentally reset — and the companies being formed or scaled today are making bets that would have seemed impossible five years ago.

$86.7B

Satellite manufacturing
market by 2035

14.8%

CAGR 2025–2035
fastest-growing segment

~5/day

SpaceX Starlink
satellite production rate

The shift is structural. LEO constellations, defense proliferated architectures, and sovereign space programs are all pulling in the same direction: more satellites, built faster, delivered to more demanding customers. Boeing's Millennium Space Systems opened a new El Segundo production line targeting 26 satellite deliveries across its portfolio in 2026. L3Harris reached full-rate production for SDA satellites at its Palm Bay facility by late 2025. Rocket Lab evolved from a launch startup to an SDA satellite prime contractor — and had to build an entirely new production capability to do it.

The engineering achievements that enabled this moment are real and remarkable. Electric propulsion systems have matured. High-power bus architectures that were once reserved for legacy GEO operators are now being productized for constellation deployment. Vertical integration — building subsystems in-house rather than procuring from the established supply chain — has compressed cost and schedule for the programs willing to invest.

The engineering challenges of this era are increasingly solved. The operational challenge — building execution infrastructure that scales with production ambition — is where most programs are underprepared.

What hasn't kept pace with the engineering progress is the operational infrastructure that makes high-cadence, high-quality production repeatable. Procedure execution, AIT documentation, subsystem qualification records, acceptance traceability — these capabilities were adequate when programs built one or two satellites per year with a founding team that carried the knowledge in their heads. They break at production rate.

The programs that will define the next decade of satellite manufacturing are the ones making the right operational investments now — before the production ramp exposes the gap.

02 · The Craft-to-Industrial Gap

Every Program Starts
as a Craft Operation.

The first satellite a company builds is always a craft operation. A small team of expert engineers, most of whom were involved in the design, build and test the hardware with deep institutional knowledge. Every decision is made by someone who understands the full system. Deviation management is handled in real time, by judgment. The procedure is often in someone's head.

This model produces remarkable results. Some of the most technically impressive satellites ever built were first articles created by founding teams operating under conditions that would terrify a traditional prime contractor's quality assurance organization. The knowledge concentration is extreme — and it works, precisely because the team is small enough that everyone knows what everyone else is doing.

"The first satellite is built by the founders. The hundredth is built by someone who joined six months ago. The procedure library is the only thing that bridges that gap."

// Operational pattern · Scaling satellite programs

The transition from craft production to industrial execution is the hardest operational challenge in satellite manufacturing. It is not a technology problem. It is not a funding problem. It is an organizational and infrastructure problem — and it surfaces differently at each stage of the production ramp.

Craft Production Model

Team size: 10–30 people, most involved in design

Knowledge location: In engineers' heads, partially captured

Procedure execution: Interpreted by experts with full context

Deviation handling: Real-time judgment by someone who designed the system

Quality record: Assembled after the fact from notes and memory

Scalability: Limited to the team that built the first article

Industrial Production Model

Team size: 100–500 people, most didn't design the hardware

Knowledge location: Must live in executable procedure libraries

Procedure execution: Must be enforceable without expert interpretation

Deviation handling: Must be captured at the step level for traceability

Quality record: Must be built automatically as work is executed

Scalability: Defined by the quality of the execution infrastructure

The transition is not triggered by a single event. It happens gradually, and it becomes visible when things start breaking: when a technician runs a superseded procedure because they didn't know it had been updated; when an anomaly investigation requires reconstructing what happened from memory because the execution record was never captured; when a new engineer can't complete a build step without asking someone who was there for the first article.

By the time these symptoms appear, the program is already behind on building the infrastructure that prevents them.

03 · Three Failure Modes

How Production Programs
Break at Scale

The operational failure modes in satellite manufacturing are consistent across programs. They appear at different points in the production ramp, but they are rooted in the same underlying gap: the absence of a systematic execution layer between what engineering specifies and what operators actually do.

FAILURE · 01

Version Drift

A procedure is updated following a design change. The engineering team knows. The update is in the system. But the operator on the production floor runs the previous version — either because the update didn't propagate to the right place, or because no one told them, or because the notification system is an email thread that got buried. The build step is executed against a superseded procedure. The deviation isn't caught until integration, or acceptance, or not at all.

At craft scale, this is recoverable. Someone who was in the room when the design changed catches it. At production rate, with operators who weren't part of the design process, version drift accumulates silently.

FAILURE · 02

Record Fragmentation

Manufacturing records, test records, and AIT records are maintained in separate systems — or worse, separate documents — without a coherent link between them. When an anomaly occurs, the investigation requires accessing multiple disconnected sources and reconstructing a timeline from memory, email threads, and handwritten notes. The corrective action documentation that a DoD customer requires cannot be assembled from retroactive reconstruction. It needs to have been captured contemporaneously — at the step, by the operator who performed it.

A fragmented record is not a complete record. It is a gap waiting to surface in an acceptance review.

FAILURE · 03

Institutional Knowledge Loss

The senior engineer who designed the subsystem and knows why every procedure step exists the way it does gets hired away. The founding team disperses as the program grows. The launch operations lead who developed the acceptance checklist from twenty years of experience departs. Their successor can execute the procedure. They cannot explain why specific criteria are set where they are, or what deviation threshold is waivable under what conditions.

The procedure checklist remains. The judgment leaves. In the NewSpace ecosystem, where mobility between programs is high and founding teams rarely stay together through full production ramp, this failure mode is endemic.

None of these failure modes require a catastrophic event to cause serious program damage. Version drift produces rework. Record fragmentation produces audit failures. Institutional knowledge loss produces quality regression. Together, they compress schedule, inflate cost, and erode the customer confidence that sustains a constellation contract.

04 · What Vertical Integration Actually Demands

The Moat That Multiplies
the Operational Complexity

Vertical integration has become the defining strategic choice of the leading NewSpace satellite manufacturers. Building subsystems in-house — avionics, propulsion, power systems, structures — compresses the supply chain, accelerates iteration, and eliminates the quality variation that comes from relying on external suppliers. For programs like K2 Space, where 85% of GRAVITAS's components were designed and built in-house, vertical integration is the core competitive advantage.

It is also an operational complexity multiplier that most programs underestimate until they are in the middle of the production ramp.

When a traditional satellite manufacturer procures a subsystem from a qualified supplier, the supplier owns the procedure library, the qualification documentation, the test execution records, and the acceptance traceability for that subsystem. The satellite manufacturer receives a qualified unit with a data package. That data package is the supplier's operational problem.

When a vertically integrated manufacturer builds that same subsystem in-house, every one of those documentation requirements belongs to them. The avionics qualification procedure. The propulsion test record. The power system integration sequence. The AIT acceptance checklist. The nonconformance history for every unit that deviated from spec during production. At one satellite per year, this is manageable. At 100 satellites per year, it is an industrial-scale documentation program that requires systematic infrastructure.

85%

K2 Space GRAVITAS
components built in-house

~500

Discrete procedure steps
per complex satellite build

100x

Documentation burden increase
craft to full production rate

Vertical integration is the right engineering decision. It is also a decision that commits the program to owning the full execution documentation burden for every subsystem they build. That burden requires systematic infrastructure — not heroic effort.

The programs that have scaled vertical integration successfully — SpaceX being the most visible example — did not scale it by hiring more people to manage more documents. They scaled it by building execution infrastructure that makes documentation a byproduct of doing the work correctly, rather than a separate activity that follows it. When an operator at McGregor completes a Merlin engine test, the execution record is built step by step as the procedure runs. The documentation package is not assembled before the qualification review. It exists because the work was done in a system designed to capture it.

That is the standard that vertical integration at production rate requires. And it is the standard that most programs scaling today are not yet meeting.

05 · The Defense Standard

Defense Customers Don't Accept
Retroactive Documentation

The fastest-growing customer segment for high-capability satellite manufacturers in 2026 is national security. The Space Development Agency Tranche programs, Space Force commercial procurement, and bilateral sovereign constellation contracts are generating hundreds of millions of dollars in committed backlog for satellite manufacturers that can meet the delivery and quality requirements. The requirement that is most consistently underestimated is the execution documentation standard.

Defense procurement organizations — the SDA, the Space Force, the national security agencies that fund sovereign constellation programs — do not accept a satellite based on final test results alone. They require a defensible, step-level execution record that traces every critical procedure from the first assembly step through final acceptance testing. That record must demonstrate not just that the satellite passed acceptance testing, but that the procedures used to build and test it were the correct, approved revisions — executed by credentialed operators, with deviations captured and dispositioned in real time.

REQ.01

Procedure traceability: Every build and test step must be traceable to a specific, version-controlled procedure. Execution against a superseded revision is a finding, not a waiver.

REQ.02

Operator credentialing: Each procedure step must be signed off by a credentialed operator with the appropriate qualification for that task. Unsigned steps are incomplete records, not minor oversights.

REQ.03

Contemporaneous capture: Execution data must be captured at the time the step is performed, not reconstructed afterward. Retroactive documentation is routinely rejected in acceptance reviews.

REQ.04

Deviation documentation: Any deviation from the approved procedure must be documented at the step where it occurred, linked to a nonconformance record, and dispositioned before the next dependent step proceeds.

REQ.05

Corrective action closure: For programs with post-delivery or post-anomaly review requirements, corrective actions must be traceable to specific procedure steps — not reconstructed from memory under licensing pressure.

These requirements are not new. They reflect the documentation standard that defense primes have operated under for decades. What is new is the number of commercial satellite manufacturers — many founded by engineers from SpaceX, Google, and academic programs — who are winning defense contracts without having built the operational infrastructure to meet these standards at production rate.

The gap between winning a defense contract and delivering a satellite that passes acceptance review is an operational gap, not an engineering gap. It is closed by execution infrastructure built before the first acceptance review — not scrambled together after the first finding.

The satellite manufacturers entering the defense market in 2026 and 2027 will be evaluated on their ability to meet this standard. The ones that built their execution infrastructure before their first delivery will pass. The ones that didn't will learn the cost of the gap the hard way.

06 · How the Programs That Scaled Built

The Infrastructure
Comes Before the Ramp

The programs that have achieved sustainable production rate in complex aerospace manufacturing share a consistent pattern: they built their execution infrastructure before they needed it. Not after the first quality failure. Not during the production ramp under delivery pressure. Before the ramp, when there was still time to build it correctly.

Procedure libraries are built from the first article, not documented afterward

The programs that scale do not build their first satellite and then document what they did. They execute the first article in a system designed to capture the procedure as it runs. The documentation is a concurrent output of the build, not a retrospective effort. The first article's execution record becomes the baseline procedure for every unit that follows.

Qualification documentation is built test by test, not assembled before submission

SpaceX's Merlin 1D qualification ran 28 tests and accumulated more than 1,900 seconds of test time. The qualification documentation was not assembled before the submission package was due. It was built, test by test, as a concurrent output of execution. By 2024, McGregor averaged seven engine test fires per day. The record is created as part of execution — not as a separate task that follows it.

Institutional knowledge is captured in executable form, not carried by individuals

The programs that sustain production rate through team transitions are the ones that encoded the knowledge of their founding engineers into procedure libraries, not just job descriptions. When the engineer who designed the abort criteria leaves, the procedure that implements those criteria — and the rationale for why they are set where they are — survives in the system. Knowledge becomes organizational before the people who hold it move on.

Compliance becomes a byproduct of execution, not a reporting exercise

The programs that move fastest through acceptance reviews are the ones that arrive with complete contemporaneous records, not the ones that scramble to reconstruct documentation before the review date. When every step is captured in real time, the acceptance package exists before anyone asks for it. Audit-readiness is a continuous state, not a pre-review sprint.

The programs that reached production rate at the highest cadence did not treat operational infrastructure as a problem to solve after first article. They built it as a prerequisite — and the production ramp that followed was the downstream consequence of that investment.

Rocket Lab's Electron reached orbit on its second flight — eight months after the first flight failed. The corrective action cycle was fast because the qualification record from Flight 1 was complete enough to support the corrective action demonstration. The program did not reconstruct what had happened. The record existed. From Flight 2, Rocket Lab moved to commercial operations, established monthly cadence by 2020, and completed 21 successful Electron missions in 2025. The qualification cadence that followed was the downstream consequence of the operational infrastructure built before Flight 1.

07 · The 2026 Window

The Operational Decisions
Being Made Right Now

The satellite manufacturing industry in 2026 is at the precise moment where operational infrastructure decisions made today will define production outcomes through 2028 and beyond. The programs that have launched their first production units — or are about to — are making choices that will either support production rate or constrain it. Most of those choices are not visible in press releases or funding announcements.

They show up in whether the second satellite is built faster than the first, or whether it takes just as long because the execution knowledge from the first article is still in the founding team's heads. They show up in whether the first DoD acceptance review is a smooth handoff or a documentation scramble. They show up in whether the Giga platform development program can leverage the procedure library from Mega production — or whether it starts from scratch because the Mega execution infrastructure was never systematically built.

S.1

If an anomaly occurred on your next build event, how long would it take to produce a complete, step-level record of what was executed, by whom, and against which procedure revision?

S.2

Is your first article's execution record complete enough to serve as the baseline procedure for your second build — or does someone need to remember what actually happened?

S.3

Is your AIT acceptance documentation building itself automatically as you execute, or will it need to be assembled retroactively before your first customer delivery review?

S.4

When a key engineer leaves your program — as they will — what happens to the operational knowledge they carry? Do you have a systematic answer, or a hopeful one?

S.5

When you transfer your production procedure library from your first platform to your next platform, is that a controlled migration in an execution system — or a document reorganization exercise?

The programs that reach production rate on their ambition — not a compromise of it — will not have done so by having better satellites. They will have done so by building, before the production ramp, the operational infrastructure that makes the gap between first article and hundredth article a repeatable process rather than a heroic effort.

The window to build that infrastructure correctly is narrow. It is before the second satellite, not during the production ramp. It is before the first DoD acceptance review, not after the first finding. It is before the next platform development program begins, not when the procedure transfer reveals how little was systematically captured.

The programs making those investments right now are the ones that will define what satellite production at scale looks like by 2028.

// About Epsilon3

Built by
Aerospace
Operators

Epsilon3 is a procedure management and operations platform used by satellite manufacturers, launch providers, and defense operators to execute and document complex procedures — from subsystem qualification testing to satellite integration to acceptance operations.

The observations in this report are drawn from the programs we have worked with across the lifecycle of satellite and launch vehicle development. We wrote this not as a product pitch, but as a field note from inside the problem — the kind of note we would want to read if we were standing up a production program for the first time. If any of it resonates with what you are seeing in your own program, we would be glad to compare notes.

No deck. Just a conversation.

Request a program briefing →