NASA has a plan to build a permanent base on the moon. What it lacks, according to a growing chorus of critics inside the space industry, is the software architecture to actually run one.
The agency’s moon base program, described as a multi-billion dollar, three-phase effort to establish sustained human presence at the lunar south pole, has generated enormous enthusiasm about hardware: habitats, nuclear reactors, pressurized rovers, communications relay satellites. But as one former SpaceX engineer recently argued, the program faces a less glamorous and potentially more dangerous problem. The software systems that would stitch together dozens of contractors, international partners, and mission-critical operations were designed for a different era of spaceflight. They are not ready for what’s coming.
The Scale of the Problem
Phase One of the moon base program alone calls for 25 launches and 21 landings. NASA is working with dozens of international partners for the initiative. Administrator Jared Isaacman has indicated the agency intends to work with multiple launch providers, aiming for crewed landings every six months with additional opportunities for new entrants. That’s an operational tempo NASA hasn’t attempted in decades, and it requires a kind of cross-organizational coordination that current space software simply wasn’t built to handle.
A permanent lunar base demands an interdependent stack of software systems managing everything from vehicle assembly procedures and work authorization to life support, on-base control systems, supply chain management, and mission planning tools. Each of these functions involves different contractors, different data formats, and different institutional cultures. The question is whether they can all talk to each other in real time.
Right now, the answer is mostly no.
Legacy Systems Built Around Contractual Boundaries
The core of the argument, laid out in detail by Laura Crabtree, CEO of the operations software company Epsilon3, is that space organizations still operate with software systems designed decades ago. These systems were built not around operational efficiency but around contractual boundaries, the legal and organizational walls that separate one contractor’s work from another’s. The result is a patchwork of fragmented, incompatible records. Critical updates travel by email, PDF, and spreadsheet. Shared version control is rare.
This matters more than it might sound. When you’re running a single mission with a single prime contractor, information silos are manageable. Annoying, but manageable. When you’re building a base that requires dozens of missions from multiple providers across multiple nations, those silos become potential failure points. A missed specification change, a delayed update to a life support procedure, a supply chain miscommunication between partners on different continents: any of these could cascade into something serious.
Crabtree, a veteran of SpaceX who worked on the Dragon program and commercial crew missions, has direct experience with the gap between what modern space operations require and what legacy infrastructure delivers. Her company now supports numerous space, defense, and advanced manufacturing organizations, giving her a wide aperture on how the industry actually operates behind the press releases.
The Track Record of Software Failures in Space
This isn’t a hypothetical risk. The space industry already has a body count of missions damaged or destroyed by exactly the kind of software and data coordination failures that a lunar base would magnify by orders of magnitude.
In 1999, NASA’s Mars Climate Orbiter was lost because one engineering team used imperial units while another used metric, and no integrated system caught the discrepancy before the spacecraft burned up in the Martian atmosphere. A $327 million mission, killed by a unit conversion error that traveled unchecked across a contractor boundary. In 2020, Boeing’s Starliner OFT-1 capsule suffered a mission-critical software timing error that nearly led to catastrophic thruster failure; a subsequent review found a second, independent software defect that had also gone undetected through testing. NASA’s own review board concluded that Boeing’s fragmented software verification process was a root cause. And more recently, the 2023 failure of Astrobotic’s Peregrine lunar lander, which suffered a propellant leak shortly after launch, underscored how quickly things go wrong when hardware-software integration across complex contractor relationships doesn’t hold under real conditions.
Each of these incidents involved a relatively contained mission profile: one spacecraft, a limited number of partners, a defined scope. A permanent lunar base multiplies every one of those coordination surfaces. The failure modes don’t add; they compound.
AI Won’t Save a Broken Foundation
There’s been predictable excitement about artificial intelligence solving these coordination problems. And AI could, in theory, dramatically improve the efficiency of lunar base operations. But the prerequisite is data integrity. AI systems are only as good as the information they process, and if that information is scattered across incompatible databases, locked inside contractor-specific formats, or arriving days late via email attachment, no amount of machine learning will compensate.
The Apollo computers had less processing power than a modern smartwatch. Processing power is no longer the constraint. Institutional architecture is. NASA needs unified data standards, shared operational platforms, and real-time information flows across organizational boundaries before any AI layer can deliver value. This is boring, unglamorous work. It doesn’t show up well in concept art or congressional testimony. But without it, the gap between NASA’s hardware ambitions and its operational capacity will only widen as the program scales.
The Contractor Coordination Challenge and the Budget to Fix It
NASA’s revised Artemis architecture makes the software problem more urgent, not less. The agency is incorporating competitive commercial rockets from SpaceX, Blue Origin, and others. It has adjusted plans for the Lunar Gateway orbital station and is repurposing components for surface operations. A SpaceX Starship rocket is one option for future launches, with a different Starship variant serving as a lunar lander. Blue Origin is developing its own lander.
Each of these providers brings its own engineering culture, its own data systems, its own operational cadence. Adding dozens of international partners multiplies the complexity further. Artemis II is already testing systems integration between the Orion capsule and its service module. Future missions will require integration at a scale that makes Artemis II look simple.
The old Gateway architecture, whatever its flaws, at least provided a single docking node where different systems met. Without it, direct crew transfers to landers place even greater demands on software coordination. Every rendezvous, every supply delivery, every crew rotation becomes a fresh integration challenge.
And the money to fix this is already in the room. Analysts estimate NASA will have spent over $100 billion on return-to-the-moon plans through the mid-2020s in inflation-adjusted dollars. The moon base program adds billions more over several years. Within those enormous sums, the cost of building a proper software backbone would be a rounding error. The cost of not building one could be measured in mission delays, integration failures, and lost strategic position. Some of the urgency comes from the geopolitical clock. Administrator Isaacman has noted the competitive timeline with China’s lunar ambitions, emphasizing that efficiency gains from better software integration aren’t optional. They’re on the critical path.
The pattern is familiar in large government programs. Hardware gets funded because it’s tangible. Software gets funded as an afterthought because it’s not. The result is systems that look impressive in photographs but struggle to function as a coordinated whole.
Why This Matters Beyond the Moon
The software architecture NASA builds for its moon base won’t stay on the moon. Whatever operational infrastructure emerges from this program will set the template for how multi-national, multi-contractor space operations work for decades. It will shape how NASA eventually mounts crewed missions to Mars. It will determine whether the fuel cells, habitats, and life support systems being developed by commercial partners can actually interoperate in the field.
According to NASA’s Moon Base Program, the agency is working to build what officials have described as humanity’s first deep space outpost. Building an outpost is hardware. Operating an outpost is software. The agency has been specific about the first. It needs to get equally specific about the second.
The hardware vision for the moon base is ambitious and, by most assessments, technically sound. Nuclear power, pressurized rovers, phased construction. All credible. But a base is an operation, not a collection of objects. And operations run on information: who knows what, when they know it, and whether that knowledge is current and correct.
If NASA addresses the software problem with the same energy it’s bringing to the hardware problem, the moon base has a real shot at working. If it treats software as a contractor-by-contractor afterthought, the way the space industry has for most of its history, then even perfect hardware won’t be enough.
The rockets are real. The reactors are coming. Here’s what should happen next: before a single Phase One contract is finalized, NASA should issue a mandatory interoperability standard, a common data exchange specification that every moon base contractor, domestic and international, must adopt as a condition of participation. Not a suggestion. Not a best practice. A requirement, baked into the contract language, with a funded integration testbed where contractor systems are validated against each other before hardware ever leaves the ground. The Department of Defense did something analogous with its Joint All-Domain Command and Control initiative. NASA doesn’t need to reinvent the model. It needs to adopt one, and it needs to do it now, while the contracts are still being written and the institutional concrete hasn’t yet set.
Photo by Wolfgang Weiser on Pexels