The problems space
does not solve.
Inorbii is not building a fantasy. Orbital compute is a serious engineering project with serious constraints. Below is what we are taking seriously — because these are the constraints that determine whether the platform is ever real.
Launch economics
Launch cost per kilogram has fallen dramatically and continues to fall. It has not, however, fallen to the point where arbitrary compute belongs in orbit. Early deployment is gated to workloads where orbital characteristics provide enough value to absorb launch cost.
→ Focus on high-value, energy- and thermal-sensitive workloads first.
Radiation & chip reliability
Ionising radiation damages silicon. Single-event upsets, cumulative dose effects, and total-ionising-dose limits constrain which devices survive, for how long, and at what performance. Shielding helps but adds mass.
→ Rad-aware silicon selection, redundancy, ECC, and graceful degradation are core to the platform, not afterthoughts.
Shielding trade-offs
Every gram of shielding is a gram that was not compute, solar, or radiator. The shielding strategy interacts with launch cost, thermal envelope, and orbital choice. There is no free protection.
→ Shielding is optimised as part of the system, not applied uniformly.
Repair & servicing
In-orbit servicing is still an emerging capability. Assuming it is cheap, fast, or routine is wishful thinking. Platforms must be designed with failure in mind — modular, redundant, and tolerant of partial loss.
→ Design for survivable degradation; treat each module as potentially unserviceable.
Thermal complexity
Space is not a refrigerator. Waste heat only leaves by radiation, and only if emissive surfaces are well-sized, oriented, and shaded correctly. Thermal mismatch is one of the primary ways orbital compute fails.
→ Thermal design defines the achievable compute envelope.
Latency & bandwidth
Propagation delay and ground-station visibility mean orbital compute is not the right layer for latency-sensitive user traffic. Bandwidth between orbit and Earth is also finite and contested.
→ Target workloads are training, batch inference, scientific, and archival — not real-time serving.
Hardware refresh cycles
Terrestrial compute benefits from rapid hardware refresh. In orbit, refresh is expensive and infrequent. Platform architecture must anticipate slower renewal and longer useful life per node.
→ Architectures that embrace redundancy and staged upgrades, rather than frequent replacement.
Debris & orbital risk
Orbital debris is a shared-systems risk. Responsible operators plan for collision avoidance, end-of-life deorbit, and conservative operational behaviour. Debris is an engineering problem, a regulatory problem, and a stewardship problem at once.
→ Debris mitigation is treated as part of platform design and mission operations.
Regulatory & economic complexity
Frequency coordination, launch licensing, export control, cross-border data policy, insurance, and end-of-life responsibility all shape what is deployable, where, and when. These are not solved by engineering alone.
→ Deployment planning is as much institutional as technical.
“We would rather be honest about what is hard than build a brand on promises the engineering cannot keep.”
This page will evolve as the program matures. The challenges listed here are not obstacles to our message — they are the message. An infrastructure company worth trusting is one that tells you what it has not yet solved.