The Second Wave of Commercial Satellite Constellations: Engineering Lessons from the First Wave
Starlink has more than 6,000 operational satellites on orbit. OneWeb survived bankruptcy to build a functioning LEO broadband network. Planet demonstrated that a constellation of small satellites could deliver something genuinely useful to commercial customers at a cadence no traditional program could match. The first wave proved the concept. It also generated a body of engineering scar tissue — hard-won knowledge about what breaks, what scales, and what quietly poisons a program from the inside — that the second wave is only partially absorbing.
The second wave is broader and more technically diverse than the first. It includes broadband LEO operators competing directly with Starlink, IoT connectivity players targeting asset tracking and industrial sensing markets, and a new generation of Earth observation companies promising hyperspectral, SAR, and video capabilities at constellation scale. Some of these organizations have seasoned space systems engineers. Many do not. Almost all of them are moving faster than their engineering processes were designed to handle.
What follows is an analysis of the specific systems engineering lessons the first wave generated, where they were actually learned versus papered over, and what the second wave is getting wrong in predictable and avoidable ways.
The Requirements Problem Nobody Talks About
The aerospace industry has a requirements management orthodoxy: write requirements in a document, put the document in a tool like IBM DOORS or Jama Connect, maintain traceability from stakeholder needs down to component specifications, and verify against that chain. For a single satellite or a constellation of three or four, this orthodoxy is workable. It is slow, document-heavy, and produces traceability that is more often demonstrated than used — but it works.
At constellation scale, it collapses.
The specific failure mode is not that requirements become incorrect, though they do. The failure mode is that the requirement set becomes unmaintainable at the rate of change the program actually experiences. Starlink’s early satellite variants went through significant design changes between Starlink v0.9 and v1.0 production. Each change had downstream effects on dozens of subsystems. In a document-based requirements environment, propagating a change through a full constellation-scale requirement set — tracking what broke, what needs re-verification, what new requirements the change implies — takes weeks. When you are launching batches of 60 satellites and your design is still evolving, you cannot afford weeks.
What first-wave programs actually did, mostly, was stop maintaining the traceability. Requirements documents became artifacts of record that did not reflect the current design. Engineers worked from tribal knowledge, Slack threads, and engineering change notices that were insufficiently connected to the formal requirement structure. Verification was performed against what the satellite actually was, not against a traced requirement chain.
This is not a condemnation of the engineers involved — it was often the only rational response to schedule pressure. But it means that second-wave programs inheriting first-wave engineering artifacts are inheriting systems whose requirements structure does not accurately represent the design decisions that were actually made. When the second-wave team attempts to build on those artifacts, they are building on a foundation with unmarked load-bearing walls.
The fundamental issue is that document-based requirements management was designed for a world where requirements are relatively stable and changes are infrequent. Constellation programs operate in the opposite world. The engineering lesson is that traceability infrastructure needs to be graph-based, not document-based — a living model where changes propagate automatically across the dependency graph, where the cost of a change is visible before it is made, and where verification status is a property of the model, not a manually maintained spreadsheet.
Factory Integration: The Software-Hardware Interface at Production Rate
Planet’s approach to manufacturing at Dove satellite scale was genuinely novel. SpaceX’s Starlink production line in Redmond was built to produce satellites faster than any previous program. What neither anticipated fully — or at least what they did not anticipate early enough — was that factory-floor integration with flight software would become a systems engineering bottleneck that manufacturing throughput alone could not solve.
The problem has a specific structure. In traditional satellite programs, software and hardware integration happens in a dedicated integration and test phase, typically after manufacturing is largely complete. The integration environment is carefully controlled. Issues found in integration are fed back into engineering through formal processes. This works when you are building one or a handful of satellites.
In high-rate production, you cannot afford a sequential integration phase. You need to integrate flight software to hardware on the production line, in parallel with manufacturing, at a rate that matches your launch cadence. This means your integration environment is the factory floor. Your “test bench” is a production station. Your software configuration management needs to be tightly coupled to your hardware serial number tracking, because you cannot have a production satellite leave the factory with a software version that was verified against a different hardware configuration.
First-wave programs built these capabilities, but not without significant pain. The engineering lesson is that flight software needs to be treated as a first-class systems engineering artifact from the beginning of the constellation design — not as something the software team handles separately and hands off at integration. Software requirements need to be traceable to hardware interface requirements. Software versions need to be tied to hardware configurations in a model that both the engineering team and the manufacturing operations team can read and update.
The second wave is repeating the mistake. Organizations that are strong hardware shops are treating software as a late-stage integration problem. Organizations that are strong software shops are treating hardware as a constraint their software needs to accommodate. Neither posture produces a factory-floor integration process that scales.
Ground Segment Interface Complexity: The Underestimated Multiplier
OneWeb’s bankruptcy was driven by multiple factors, but the engineering lessons from their ground segment architecture are instructive regardless of the commercial outcome. Ground station interfaces for a LEO constellation are not simply a scaled-up version of a GEO ground segment. They are qualitatively different in ways that bite programs that do not model the interfaces as first-class requirements.
The core issue is that LEO constellation ground segments have to manage contact windows that are short (typically 5–12 minutes per pass), frequent (hundreds of contacts per day across a large constellation), and highly variable in link budget depending on elevation angle and atmospheric conditions. The ground-to-space interface is therefore stateful in a way that GEO ground interfaces are not — you cannot assume that a command you send will be acknowledged before the satellite passes below the horizon, and you cannot assume that the state you left the satellite in at the end of one contact will be the state you find it in at the beginning of the next.
This has cascading effects on requirements at multiple levels. At the satellite level, it implies requirements on autonomous fault management — the satellite needs to be able to handle failure conditions without ground intervention for intervals measured in hours, not minutes. At the ground segment level, it implies requirements on contact scheduling, state reconciliation, and commanding protocols that are far more complex than what a GEO-centric requirements model would generate. At the operations level, it implies requirements on operator tooling that neither hardware nor software engineers typically own.
First-wave programs that modeled ground-to-space interfaces as requirements-bearing interfaces from the beginning of their programs did substantially better than those that treated the ground segment as a late-stage implementation problem. The engineering lesson is that ground segment interface requirements need to be co-developed with satellite requirements, not derived from them after the satellite design is settled.
Second-wave IoT constellation operators face a specific version of this problem. Their ground segments are often aggregated networks of customer-operated receivers, not controlled ground station networks. The interface between the constellation and those receivers needs requirements coverage that accounts for variability in the receiver implementation — something that is genuinely hard to specify and verify, and something that most second-wave IoT operators are underweighting.
How Process Failures Compound at Constellation Scale
The most dangerous property of constellation-scale programs is that process failures are not linear. A requirements management problem that would cause moderate rework on a three-satellite program causes exponential rework on a three-hundred-satellite program. An interface definition error that would be caught in integration test on a small program propagates into production and has to be resolved across every satellite already manufactured.
This compounding effect means that second-wave programs are often underestimating their engineering risk by orders of magnitude. They benchmark their process maturity against what it took to build their first demonstration satellite, not against what it will take to sustain a production program at the rate their business plan requires.
The specific compounding mechanisms are worth naming:
Requirements drift at production scale. When requirements change during production, every satellite already in production — in some stage of manufacturing, integration, or test — needs to be evaluated against the change. At 20 satellites per month production rate, even a two-week requirements change cycle means 40 satellites in ambiguous configuration status. The cost of resolving that ambiguity is not linear in satellite count.
Interface version fragmentation. When satellite hardware and software evolve through multiple versions during a production run, the ground segment needs to support multiple interface versions simultaneously. If interface requirements were not model-based, the ground software team is maintaining compatibility with interface versions that are documented in change notices scattered across an engineering change management system, not in a single coherent model.
Verification debt. When schedule pressure causes programs to defer verification against formal requirements, that debt accumulates. For a single satellite, verification debt is painful but manageable. For a constellation, it means that a defect that escaped verification on early units may be present in hundreds of satellites on orbit before it is discovered.
First-wave operators resolved most of these problems through sheer engineering talent and organizational will. Starlink in particular has a culture and a resource base that can absorb significant engineering chaos and still deliver a functioning constellation. The second-wave operators who are attempting to replicate that outcome without that resource base are the ones at highest risk.
What Modern Tools Actually Get Right
The systems engineering toolchain available to second-wave programs is meaningfully better than what first-wave programs had access to at the start of their development cycles. The improvement is not primarily in the legacy tools — IBM DOORS Next, Jama Connect, Polarion, and Codebeamer have all added features, but their fundamental architectures remain document-centric or artifact-centric in ways that do not solve the compounding problem.
The improvement is in newer, graph-model-native tools that treat requirements as nodes in a connected model rather than as rows in a document. Tools like Flow Engineering, which was built specifically for hardware and systems engineering teams dealing with complex, rapidly-evolving requirement sets, implement this approach operationally. The practical difference is not philosophical — it is that when a interface requirement changes, the tool can immediately show you every downstream requirement that is affected, every verification that needs to be re-evaluated, and every component that needs an engineering review. That propagation is automatic. In a document-based tool, it is a manual audit that takes days and is never fully trusted.
For constellation programs specifically, Flow Engineering’s graph-based approach addresses the requirements drift and verification debt problems directly: the model is the single source of truth that both engineering and manufacturing operations read from, which eliminates the configuration ambiguity that plagues high-rate production programs using document-based RTMs.
The honest caveat is that no tool solves the constellation-scale engineering problem by itself. A graph-based model populated with poorly-written requirements, or maintained by a team that does not have the discipline to keep it current, will fail as surely as a spreadsheet RTM. Tool choice is a necessary condition for success at constellation scale, not a sufficient one.
Honest Assessment
The second wave of commercial satellite constellations will produce some successful programs and some high-profile failures. The engineering lessons from the first wave are available and reasonably well-documented. The programs that succeed will be those that apply those lessons early — before they are in production, before they have a constellation-scale requirements set that has drifted from the actual design, before they have a ground segment whose interfaces are defined well enough to implement but not well enough to evolve.
The specific capabilities that separate programs that will make it from those that will not are not primarily technical. The physics of LEO constellation design is well understood. The manufacturing processes for small satellite production are maturing rapidly. The differentiating factor is engineering process maturity: the ability to manage requirements at production scale, to integrate flight software with hardware on the factory floor, and to model ground-to-space interfaces as first-class requirements throughout the development cycle.
Second-wave programs that inherited first-wave artifacts without understanding the decisions embedded in them should conduct that audit now, before they are in production. The cost of requirements archaeology before production starts is a fraction of the cost of rework after the first batch of 60 is on orbit and not performing as expected.
The first wave proved that constellation programs are buildable. The second wave is proving that buildable and sustainable are not the same thing, and that the gap between them is almost always an engineering process problem, not a technology problem.