article
Space software cannot borrow web risk
The web assumption that software can be patched quickly is dangerous when access windows, certification and physical consequence constrain recovery.
Emil Shirokikh · Published September 11, 2026 · Updated September 23, 2026 · 2 min read
Abstract
Release velocity is not the same as learning velocity. Space software needs reproducibility, fault containment and precise configuration knowledge more than fashionable deployment rituals.
Recovery changes release policy
Web teams often assume rapid patching. Space systems face contact windows, configuration uncertainty and physical consequences that make recovery slower.
Release protocol
Produce immutable builds, a software bill of materials, hardware-in-the-loop evidence, signed release artefacts and a command-authority matrix. Rehearse rollback before launch.
Acceptance evidence
Optimize for reproducibility and fault containment, not deployment frequency.
Challenge the conclusion
Modern software practices remain useful. They must be adapted to mission constraints rather than copied by name.
Use this in a working session
Select one failed deployment scenario and prove which build is active, who can change it, how integrity is verified and how operations recover.
BELTO editorial analysis. It does not describe a client engagement or claim a commercial result.
References
2 sourcesAuthor
Emil ShirokikhFounder
Founder of Belto Inc. Writes on engineering, venture building and applied intelligence.
Related
Read next
Satellite autonomy needs boring failure modes
Autonomy in orbit is valuable precisely where communication is limited, but novelty is least useful during a fault.
Downlink is a product decision
A mission that collects more than it can move has not solved sensing; it has moved product selection into orbit.
The ground segment is the mission
Space programmes celebrate hardware while ground software quietly determines whether operators can command, understand and recover it.