How Gravitics Is Building Commercial Space Stations at Commercial Speed

The International Space Station took roughly a decade to assemble, drew on the engineering resources of fifteen nations, and cost somewhere north of $150 billion. It remains the most complex structure humans have ever assembled in orbit. It also represents a development model that no commercial company can replicate — and none is trying to.

The next generation of orbital infrastructure is being built by companies with venture backing, commercial launch contracts, and engineering teams measured in the hundreds rather than the thousands. Gravitics is one of the most technically ambitious of them. Their StarMax habitat module is designed to deliver habitable volume that dwarfs anything currently on orbit, at a cost basis that makes commercial space stations economically viable. To do that, they are applying ISS-era engineering discipline through tools that did not exist when ISS modules were being designed.

What Gravitics Is Actually Building

The StarMax module is an expandable — sometimes called inflatable — large-volume habitat designed for low Earth orbit, with architecture extensible to lunar orbit. The core premise is volumetric efficiency: a module that launches in a compact configuration and expands on orbit to provide significantly more usable interior space than the aluminum-shell modules that make up ISS.

Expandable structures have been validated on orbit before — Bigelow Aerospace’s BEAM module has been attached to ISS since 2016 and has performed well against its original specifications. Gravitics is pushing the concept much further in scale, targeting habitable volumes that would support both crew and commercial activities including manufacturing, research, and tourism.

The StarMax is not a capsule or a cargo bay. It is a destination. That distinction matters enormously for how it has to be engineered.

The Engineering Problem Is Not Structural Alone

A habitat module that humans will live and work in for extended periods is not primarily a structural problem, although structural integrity is obviously non-negotiable. It is a systems integration problem. The structural shell interacts with the environmental control and life support system (ECLSS). ECLSS interacts with power distribution. Power distribution interacts with thermal management. Docking and berthing interfaces impose mechanical and electrical constraints on everything adjacent to them. Human factors requirements — reach envelopes, emergency egress paths, noise limits, lighting levels — cut across every other domain and cannot be treated as a late-stage overlay.

On ISS, these domains were managed by separate national and contractor teams with formal interface control documents running to thousands of pages, adjudicated through a change control process that could take months to resolve a single interface question. That process produced a remarkably well-integrated station. It also took years per module.

Commercial timelines do not accommodate that model. A company like Gravitics is operating under investor timelines, NASA Commercial Low Earth Orbit Destinations (CLD) program milestones, and the competitive pressure of a market where Axiom Space, Sierra Space, Vast, and others are pursuing overlapping objectives. Slowing down to manage cross-domain requirements through document exchange is not a viable strategy.

The engineering challenge is therefore precise: maintain ISS-level rigor across human-rated hardware while moving at commercial software-company speed. That is not a cultural challenge. It is a tooling challenge.

What ISS-Era Systems Engineering Got Right — and What It Calcified

ISS-era systems engineering, practiced primarily through MIL-STD and NASA-NPR frameworks, established the foundational practices that any serious human spaceflight program must implement. Requirements decomposition from mission to system to subsystem. Bidirectional traceability between requirements and verification evidence. Formal interface control. Hazard analysis tied to requirements. These are not bureaucratic overhead. They are the mechanisms by which you find out that a change to an ECLSS fan mounting bracket affects the acoustic environment in the crew sleep quarters, before you find out on orbit.

What ISS-era tooling calcified was the document-centric implementation of those practices. Requirements lived in Word documents, then in IBM DOORS — a database-backed system that brought genuine improvement over pure document management but retained a fundamentally tabular, specification-first model. Traceability was maintained through manually updated matrices. Interface control documents were versioned but not dynamically linked to the requirements they governed. Change impact analysis required a human to walk the dependency tree.

That model is not wrong. It produced hardware that has kept humans alive continuously in orbit for over two decades. But it front-loads process in ways that assume decade-long programs with large dedicated systems engineering teams. Strip out the timeline and the headcount, and the process becomes a bottleneck rather than a safeguard.

Managing Five Domains With One Source of Truth

Space habitat development at Gravitics spans, at minimum, structural and mechanisms engineering, ECLSS, power and thermal systems, docking and proximity operations interfaces, and human factors and habitability. Each domain generates requirements. Each domain’s requirements constrain and are constrained by requirements in adjacent domains. And all of them carry human safety implications that require verification evidence — not just analysis, but test data, inspection records, and formal V&V closure.

This is precisely the environment where the limitations of document-based requirements management become acute. When a structural analysis updates the load path through the docking interface, every ECLSS line routed near that interface, every human factors clearance defined relative to that interface, every power distribution node attached to that interface potentially needs to be re-evaluated. In a document-based system, finding all of those downstream effects requires institutional knowledge about where the connections are. If the person who knows where the connections are is not in the room, some of them get missed.

A graph-based model — where requirements, design nodes, interfaces, and verification events are connected objects in a traversable network — changes the nature of that problem. When the interface definition changes, the system can identify every requirement that traces to it, every verification activity that closes against it, and every design element that implements it. The impact analysis is not a separate manual task. It is a query.

Gravitics uses Flow Engineering to run faster development cycles for complex space hardware by managing design, requirements, and V&V in a single connected environment. For a program spanning multiple engineering domains with safety implications at every interface, having that connectivity resident in the tooling rather than in spreadsheets and people’s heads is not a convenience. It is a structural property of how the program manages risk.

Commercial Speed Does Not Mean Reduced Rigor

There is a version of this story that frames modern tooling as a way to move faster by doing less. That framing is wrong, and it is worth being explicit about why.

The commercial space station programs that will survive long enough to put paying customers on orbit will be the ones that find every load-path conflict before the structural test, every ECLSS pressure balance issue before the qualification campaign, every human factors clearance problem before crew ingress. The V&V discipline does not get lighter because the timeline is compressed. What changes is the mechanism by which that discipline is maintained.

When requirements, design intent, and verification evidence all live in connected objects rather than separate documents, the systems engineering rigor becomes continuous rather than episodic. You do not wait for a formal requirements review to find out that a new design decision has left three requirements without a verification path. The gap is visible as soon as the design decision is made. That is faster, but it is also more rigorous — not less.

The Broader Pattern in Commercial Space

Gravitics is not alone in this approach. The commercial space sector more broadly is the first human spaceflight ecosystem built primarily on modern tooling rather than retrofitted legacy systems. The generation of engineers leading these programs grew up with Git, with Jira, with cloud-native collaboration tools, and they are not interested in reverting to client-server database applications from the early 2000s to manage requirements.

That generational shift is enabling a different kind of systems engineering practice — one where traceability is a byproduct of how work is done rather than a separate documentation effort, and where the model of the system is live and connected rather than a snapshot frozen in the last published specification.

The ISS taught the industry what questions to ask. The commercial programs that follow it are building the tooling infrastructure to answer those questions faster. Gravitics, with one of the most technically ambitious module programs in the sector, is an instructive case study in how those two things fit together.

Whether StarMax reaches orbit on schedule will depend on engineering execution across dozens of domains over several years. What the program’s approach to systems engineering suggests is that the foundational infrastructure for managing that complexity is more capable, and more connected, than anything available to the teams that built the station it hopes to complement.