starGRID

STARGRID proposes an orbital automation layer — a powerful, space-located computational cluster that gives nanosatellite operators the backhaul, compute and virtualization they currently rent from a sprawling ground segment.

The premise is simple: as constellations grow into the hundreds and thousands, the ground-initiated, command-and-control style of operations cracks under its own weight. Bandwidth becomes the bottleneck. Provisioning a 1000-satellite constellation conservatively requires more than a hundred ideally positioned ground stations — and most of what they downlink is data with no features of interest.

STARGRID inverts the topology. A meshed grid of compute-heavy nanosats sits between customer satellites and the ground, exposing a virtual machine, a connectivity hook, and a modular bus as the three primitives operators build on. Customers focus on their mission payload. STARGRID handles the rest of the stack.

The CubeSat form factor democratised access to orbit, but the operations layer didn’t keep up. We inherited a model where everything important happens on the ground.

Four converging constraints

The old ground-initiated command-and-control style systems aren’t going to work for these finer-grained systems.— STARGRID Pitch, §04

Use case: a 22-antenna data-intense constellation

The math gets ugly fast. Ten-minute downlink windows. Nine sats per antenna per pass. The result: high latency from capture to receipt, scalability ceilings, an expensive shared ground segment, and a forced CAPEX-over-OPEX design choice.

Source · Lucia & Denby, “Orbital Edge Computing: Nanosatellite Constellations as a New Class of Computer System.”

STARGRID is a meshed compute cluster in LEO. It exposes computation, storage, AI co-processing and inter-satellite connectivity as services. Customer satellites connect through a single hook; their operations team interacts with a virtual machine instead of a ground station network.

The shift is architectural, not just operational. Customers stop bending their satellite design around bandwidth scarcity. They get a programmable surface — a virtualization environment in orbit, a “Firmware Over The Space” workflow, real-time delivery between adjacent and opposing satellites, and one-click reconfiguration up to 1,000 nodes. The grid is architectural-decision agnostic: anything from Earth observation to deep space can plug in.

Three primitives. A modular bus to host the stack, a hook to attach a third-party satellite, and a virtual machine that exposes the grid as a programmable surface.

Today’s allocation of effort between ground and space is upside-down. STARGRID is built for the ratio that comes next.

In-space tasks are dark · ground tasks are light · accent indicates the inversion.

Hypotheses, with the math behind them. Each figure is a working assumption — to be tested against real customer data during the experiments laid out in WP1.

The grid is a horizontal layer; the verticals are anyone running fleets. Six customer groups identified during the value-proposition design loop.

Revenue streams (hypotheses)

We organised the validation effort into three work-package streams and one management framework. Each stream runs as a build–measure–learn loop with explicit exit criteria. The framework is shareable; the contents are not.

Methodology · build–measure–learn loop · weekly Monday focus group, Wednesday review · exit criteria gating each loop.

STARGRID was a study in what it takes to make a deep-tech venture legible — to engineers, to investors, to a customer who has never bought from us before.