The moon base has a hardware plan. It needs a software strategy, too.

Early in my career at SpaceX, I was the only person dedicated to training the mission control team for Dragon. For three years, I built the training for the operations team. The documentation came second, always the thing I’d get to later, always the thing that felt like overhead against the actual work of getting the mission ready.

Then we needed to scale. What followed were months of reconstructing decisions that should have been in the record from day one: how certain anomalies worked, different places we could start and stop the mission, hundreds of little choices that could affect how training was executed, communicated and debriefed. The operational debt accumulated by deferring that work was more expensive than any hardware redesign. It just took longer to be realized.

NASA’s moon return plans announcement this week has me thinking about that lesson. Specifically, how it will affect the new era of human space exploration as space boots meet space ground once again.

Right vision, right moment, new momentum

NASA Administrator Isaacman laid out the right vision for the right moment at Ignition. America wins with a permanent lunar base, built in deliberate phases. We win the second space race through crewed landings every six months from two independent providers, an aggressive CLPS expansion, a nuclear propulsion demonstrator to Mars in 2028 and a long-horizon demand signal that extends well beyond Artemis 5. 

NASA at the helm is a great thing. NASA is doing what it does better than anyone else: articulating the direction the private market alone couldn’t coalesce, convening 60-plus international partners and the most capable commercial space ecosystem in the world and making the generational bets that will move civilization forward into permanent habitation beyond our Earth. 

As Isaacman put it directly: “Please do not go back to the moon just for the footprints and the flags. You must pick up where we left off more than a half century ago, build the moon base, create an enduring presence.” Both the ambition and the urgency align with progress.

But ambition alone can’t sustain a permanent lunar base. How NASA and the combined force of the commercial space sector build, test and execute will decide success. It’s hardware-led, but the execution of a program of this scale and magnitude can’t run on software that wasn’t designed for it. 

Take me (back) to the moon

Lunar travel is steeped in precedence. But it’s a completely different era of innovation since the last time a crewed American mission landed on the lunar surface.

Apollo famously flew to the moon on computers with less processing power than the smartwatch on your wrist today. The software running those missions was purpose-built, painstakingly engineered, and extraordinary for its time. Since then, the industry has built, in essence, its inverse: monolithic systems architected for the programs of 20, even 30 years ago, maintained by the contractors who built them, with update cycles measured in years and data rights structures that make integration across organizations a legal negotiation rather than an engineering problem. 

Companies helmed by space engineers and tech giants are both using software not even designed with space in mind for complex missions such as these. These systems have succeeded in executing missions designed for the moment and maintaining the status quo. But they’ve failed to do so at a tempo, cadence and mission complexity that keeps pace with technological innovation.

“Software” in the context of space can mean dozens, even hundreds, of different applications with specific functions. A permanent lunar base would run on an entire stack of interdependent software systems: the procedures guiding technicians through vehicle assembly and launch processing on the ground; the work authorization and supply chain management systems tracking every component across a multi-prime contractor network; the environmental control and life support systems keeping crew alive on the surface; the on-base control systems managing power distribution, thermal regulation and communications across a growing constellation of surface assets; the mission planning and scheduling tools coordinating operations across organizations that may be separated by 240,000 miles and a significant communication latency constraint. 

It’s complex, by design. Each layer of the stack is its own domain. Each has its own legacy architecture. And almost none of them were designed to talk to each other across organizational boundaries.

NASA’s operation software powering centers and activities across the defense and commercial industrial base was not designed for the tempo, the flexibility or the multi-organization complexity that the moon base era demands. Across the space, defense and advanced manufacturing sectors the pattern is consistent: organizations doing mission-critical work are operating from fragmented, incompatible records. A launch provider runs procedures in one system. Their payload customer works in another. The government oversight team receives static exports that are stale by the time they’re reviewed. The integration contractor, three levels down the supply chain, is reconciling work authorizations in spreadsheets. When requirements change (and they always change) updates propagate through email threads and PDF attachments that leave no auditable trail and no shared version of what actually happened.

Everything is fragmented. And the core issue is structural — the accumulated result of decades of programs organized around contractual walls, data rights restrictions and compliance requirements written to control behavior rather than drive outcomes. Those requirements grew heavier after every anomaly, well-intentioned each time and collectively they produced a system where the overhead of managing processes consumes resources that should be driving mission success.

AI’s lunar era 

As AI enters the conversation, the opportunity is real: AI-assisted procedure generation, anomaly detection across operational data streams, predictive maintenance for surface systems operating in environments no human can directly inspect, autonomous configuration management across a base that will eventually be too complex for any single team to hold in their heads. AI can compress the time between a lessons-learned event and an updated procedure from weeks to hours. It can surface patterns across thousands of operational runs that no analyst would catch manually. 

At the scale NASA is proposing, those capabilities are mandatory and could make the difference between a cadence that holds and one that fractures under its own weight. But AI is only as trustworthy as the data it runs on. Feed it fragmented, unversioned, organizationally siloed records — the current state of most programs — and you get confident outputs built on an unreliable foundation. 

The AI challenge in the moon base era isn’t capability. It’s data integrity. And data integrity is an operational infrastructure problem before it’s an AI problem.

Moon Base Program Executive Carlos Garcia Galan said it plainly at Ignition: “Starting today, we’re building humanity’s first deep space outpost.” Phase One alone calls for 25 launches and 21 landings, coordinated across CLPS providers, HLS contractors, science payload teams, rover developers, communications constellation operators and partners from dozens of nations, each with their own tools, their own standards, their own definition of done. 

By the time Phase Three habitation modules arrive, the software challenge goes beyond just coordinating a launch campaign to managing a living infrastructure from consumables logistics, to life support system states, maintenance records for surface assets that have been operating for years. And that’s followed by the continuous configuration management of systems being modified by crews who weren’t there when they were built.

The software enabling this era needs to match the ambition of the hardware it supports: built for reliability under pressure, designed for the operators who actually run the mission, capable of evolving at the speed of the program. Not legacy systems on maintenance contracts. Not general-purpose enterprise tools retrofitted into mission-critical workflows. Missions need software development cycles measured in weeks, not years. Requirements calibrated to what’s genuinely necessary for safety and mission success, not inherited from prior programs and left unquestioned. 

These are the conditions under which the moon base actually becomes permanent rather than episodic.

Apollo proved that software could take humans to the moon. What the moon base era requires is software capable of keeping us there. As Isaacman said, “The difference between success and failure will be measured in months, not years.”

Laura Crabtree is the co-founder and CEO of Epsilon3, the mission execution platform supporting more than 130 space, defense and advanced manufacturing organizations. Prior to founding Epsilon3, she spent over a decade at SpaceX as a mission operations engineer, serving on console for the first Dragon mission in 2010, the first cargo delivery to the ISS in 2012 and the first commercial crew delivery in 2020.

SpaceNews is committed to publishing our community’s diverse perspectives. Whether you’re an academic, executive, engineer or even just a concerned citizen of the cosmos, send your arguments and viewpoints to opinion (at) spacenews.com to be considered for publication online or in our next magazine. If you have something to submit, read some of our recent opinion articles and our submission guidelines to get a sense of what we’re looking for. The perspectives shared in these opinion articles are solely those of the authors and do not necessarily represent their employers or professional affiliations.