Second-Wave Smallsat Constellations: What Lessons from Starlink and OneWeb Actually Stuck
The first generation of commercial LEO constellations — Starlink, OneWeb, Planet Labs, Spire Global — accomplished something genuinely unprecedented: they manufactured, launched, and operated hundreds to thousands of spacecraft in timeframes that legacy primes considered impossible. The engineering feats were real. So were the process failures.
Between 2019 and 2024, the industry produced enough post-mortems, conference papers, and quiet engineering retrospectives to construct a reasonably honest picture of where first-wave programs succeeded by discipline and where they succeeded despite themselves. A second wave of constellation programs — in communications, remote sensing, weather monitoring, and commercial navigation augmentation — is now in active development. Some are flying early pathfinders. Most are in the phase where engineering decisions still have leverage.
What follows is an assessment of the systems engineering dimensions: what the second wave inherited, what it institutionalized, and where the same failure modes are re-emerging.
The First Wave’s Real Engineering Legacy
Before diagnosing lessons learned, it helps to be precise about what first-wave programs actually proved.
Mass production is a systems engineering problem, not just a manufacturing problem. Planet and Starlink both discovered that producing satellite number 300 exposed requirements ambiguities that were manageable at unit 5. Interface control documents written for prototype builds became active liabilities when production rates hit dozens per month. Engineering change orders propagated in ways that requirements management processes — most of which were adapted from single-satellite or small-batch programs — were not designed to handle. The informal tribal knowledge that bridges specification gaps on a 10-unit program doesn’t scale to 400 units across a distributed supply chain.
On-orbit software became the long tail of program cost. This was the finding that surprised even experienced primes. Launch amortizes over the constellation life. Manufacturing cost curves downward with learning. But software — updates, patches, feature additions, anomaly responses — scales with the number of operational spacecraft and never stops. OneWeb’s receivership and restart exposed how much of the operational burden was software-defined and how little of that was captured in original cost models. Starlink’s operational cadence of regular software updates across thousands of vehicles is now understood as a core competency, not a workaround.
Spectrum is an engineering constraint, not a legal sidebar. Several first-wave programs treated ITU coordination and FCC licensing as a compliance process running parallel to engineering. The consequence: architecture decisions made early in the design phase created spectrum conflicts that were expensive to resolve or simply couldn’t be resolved. Frequency plan changes that seemed minor on paper required hardware redesigns. Some programs discovered that their planned orbital shells conflicted with coordination obligations in ways their systems engineers were never told about.
Constellation-level requirements are qualitatively different from satellite-level requirements. Coverage, latency, revisit rate, and availability are emergent properties of the constellation as a system. They cannot be derived simply by specifying individual satellite performance and multiplying. First-wave programs that managed requirements primarily at the satellite level found themselves unable to clearly trace service-level degradation to specific engineering decisions. When a ground customer reported coverage gaps, the path from symptom to root cause through the requirements hierarchy was often broken.
What the Second Wave Is Doing Differently
Model-Based ICDs from the Start
The most concrete process change visible across well-run second-wave programs is the earlier adoption of model-based interface definitions. Where first-wave programs often started with document-based ICDs and attempted to migrate toward models as production scaled, second-wave programs — particularly in the defense-adjacent commercial sector — are starting in the model.
The practical consequence is that interface changes propagate automatically to downstream specifications rather than through manual document change processes. At production rates that second-wave communications constellations are targeting, this isn’t a nice-to-have. A document-based ICD process that works fine at 10 units per year becomes a change management crisis at 10 units per week.
This shift is also driving earlier investment in digital thread infrastructure. Programs that can demonstrate a connected model from requirements through manufacturing traveler are finding it easier to manage the concurrency between design iterations and production ramp. The tooling investment is non-trivial, but the programs that skipped it in the first wave paid for it later.
Software-Defined Architecture as a Requirements Driver
Second-wave programs are making software updateability a first-class requirement, not an implementation detail. This manifests in hardware decisions — more capable on-board processors, standardized software abstraction layers, explicit requirements for over-the-air update capability — but more importantly it shows up in how software is treated in the systems engineering process.
On programs where this lesson has been internalized, software interfaces are specified at the same level of rigor as RF or mechanical interfaces. Software versions are configuration-managed as design artifacts, not as post-delivery artifacts. The operational concept explicitly includes software update cadence as a design parameter that drives power, compute, and uplink bandwidth requirements.
This is not universal. Programs under cost pressure frequently let software architecture rigor slip early in development, reasoning that they’ll clean it up before launch. First-wave programs reasoned the same way.
Spectrum Coordination Integrated into Systems Engineering
The most structurally significant change in well-run second-wave programs is the integration of spectrum engineers into the systems engineering team rather than treating them as a regulatory support function. Frequency plans, polarization choices, and orbital shell definitions are now flowing into the same model space as link budgets and coverage analyses.
This integration matters because spectrum decisions constrain architecture decisions that constrain manufacturing decisions. A program that discovers at PDR that its planned spectrum allocation requires coordination agreements it cannot obtain has spent 18 months engineering a system that needs to be redesigned. Several second-wave programs have hired spectrum engineers into systems roles specifically to prevent this failure mode from recurring.
Constellation-Level Requirements Hierarchies
This is the area where second-wave programs show the most variance — and where the gap between leading and lagging programs is widest.
Leading programs are building explicit requirements hierarchies that distinguish between constellation-level service requirements (coverage, availability, capacity) and spacecraft-level performance requirements, with defined allocation methods for deriving one from the other. They are maintaining bidirectional traceability between service-level requirements and satellite specifications so that architecture trades can be evaluated against top-level service commitments.
Lagging programs are still managing requirements primarily at the spacecraft level, with constellation-level performance expressed informally in marketing materials or system-of-systems documents that aren’t maintained alongside the engineering artifacts. This produces the same failure mode that burned first-wave programs: when service performance doesn’t meet commitments, the root cause is difficult to trace and the design change required is difficult to scope.
Where the Same Mistakes Are Recurring
Honest assessment requires naming the failure modes that are re-emerging despite available lessons.
Requirements management tooling remains under-invested relative to design tooling. Second-wave programs are spending heavily on simulation, digital twin infrastructure, and manufacturing automation. Requirements management — the process of maintaining a coherent, traceable, change-controlled requirements hierarchy from customer need through verification — is still frequently managed in tools that are either legacy document repositories or spreadsheets dressed up with version control. The cost of this shows up late and is difficult to attribute to the tooling decision, which is why the pattern repeats.
Concurrency between design and production continues to create configuration management debt. First-wave programs ran design and production concurrently because schedule pressure demanded it. Second-wave programs are doing the same thing for the same reason. The lesson that concurrency requires unusually rigorous change management discipline — not just good intentions — is acknowledged intellectually but frequently not operationalized.
Inter-spacecraft and spacecraft-to-ground interface requirements are still underspecified early. Laser inter-satellite links, which are becoming standard in second-wave communications constellations, introduce interface complexity that is qualitatively harder than RF links. Pointing, acquisition, and tracking requirements, combined with thermal and vibration environments, create interface specifications that have to be correct from the start. Programs that are treating ISL interfaces with the same early-phase informality that first-wave programs applied to simpler interfaces are likely to encounter the same downstream integration problems.
Verification planning at constellation scale is not keeping pace with constellation scale ambitions. Verifying a single satellite’s performance is well understood. Verifying that a 200-satellite constellation meets its top-level service requirements involves statistical arguments, simulation validation, and in-orbit acceptance criteria that most second-wave programs have not yet resolved. Verification planning that starts at CDR, rather than at requirements definition, produces verification programs that are under-resourced and under-specified.
Where Tooling Now Makes a Difference
The tooling landscape available to second-wave programs is meaningfully better than what first-wave programs had at the equivalent stage. This matters because some first-wave failures were genuine tool limitations, not just process failures.
Modern requirements management platforms designed for complex systems can now maintain bidirectional traceability at the scale of a constellation program — across thousands of requirements, multiple spacecraft variants, ground systems, and user terminals — in a way that legacy document-based tools genuinely could not. The distinction between tools that bolt AI onto a document database and tools built from the ground up with graph-based models and AI-native architecture is real and consequential at constellation scale. Flow Engineering, built specifically for hardware and systems engineering teams, represents this second category: its graph-based requirements model is designed for the kind of cross-cutting traceability that constellation programs need, where a single change to a service-level requirement needs to propagate visibly through satellite specifications, ground system requirements, and verification criteria simultaneously.
That said, tooling is not a substitute for process discipline. Programs that adopt modern requirements management tooling without investing in the process to populate and maintain it produce well-organized repositories of stale requirements, which is only marginally better than the alternative.
An Honest Assessment
The second wave of smallsat constellation programs is engineering better systems than the first wave — with more explicit software architecture, better integrated spectrum planning, and earlier investment in model-based interfaces. These are real improvements that reflect genuine institutional learning.
The areas where improvement is lagging — requirements management rigor, verification planning at scale, configuration management discipline during concurrent design and production — are not areas of technical ignorance. The engineering community knows what good practice looks like. The gap is organizational and economic: requirements management investment competes with engineering investment for resources in the phase of a program when requirements management investment has the highest leverage.
The pattern from the first wave suggests that programs which defer this investment will spend significantly more correcting its absence in later phases. A few second-wave programs have made the institutional commitment to avoid this outcome. Most are repeating the same calculation their predecessors made — and will likely reach the same conclusion about whether it was the right one.