Space, without your own satellite. Explore the Mission Finder →

← All mission examples

Prove the software before the satellite.

An example for a software team that needs a compatibility report, not an entire spacecraft development programme.

Plan a similar mission ↗
Prove the software before the satellite.

“Our image-processing software works on the ground. We need to verify the target processor, sensor inputs and resource budget before the next satellite integration.”

An example brief, not a customer quotation.
01 / THE TASK

What needs to happen

Run a fixed validation suite on a compatible payload processor and input interface.

02 / THE CAPACITY

What you would rent

An approved software environment, representative sensor inputs, execution time and telemetry access.

03 / THE RESULT

What comes back

A compatibility matrix, execution logs and a reproducible resource-use report.

Buy the test.
Rethink the launch.

For this example, assume the following two routes to the same software test. The shared route depends on an existing payload being suitable.

DEDICATED MISSION ROUTE

Build around your own spacecraft

€150,000illustrative project budget
6 monthsillustrative planning runway

You coordinate a dedicated spacecraft or payload, integration, launch access and operations. This route offers more control over hardware and mission design.

SHARED CAPACITY PILOT

Use a compatible satellite

€18,000illustrative all-in pilot budget
14 daysexecution target after approval

Your budget covers an assumed scope of integration, payload access, execution, data return and reporting. The existing operator retains spacecraft control.

Read these numbers as scenario inputs.

They are not market benchmarks, operator quotes or measured customer savings. The dedicated route may cost more or take longer. The shared execution target starts only after compatibility checks, integration, operator approval and capacity confirmation; that preparation adds lead time. Actual scope, pricing and schedule must be agreed before a real mission.

Bring the right inputs.

  • A workload manifest covering architecture, runtime and dependencies.
  • Representative input fixtures and expected outputs.
  • Pass/fail criteria for latency, memory and output correctness.

One task. The right resources.

Target environment

A payload processor that meets the stated architecture requirements.

Test inputs

Approved representative data from the relevant sensor interface.

Validation campaign

A fixed suite with repeat runs and agreed measurements.

How the mission would run.

01

Specify the target

Record the processor, runtime, interfaces and performance limits that matter.

02

Review the package

Check dependencies and isolation requirements with the operator.

03

Execute the suite

Run the agreed fixtures and record pass/fail results plus resource use.

04

Prepare integration

Use the findings to fix incompatibilities and inform the next hardware integration.

Why shared capacity fits

The value comes from closing a specific software compatibility gap. Shared hardware is useful when its interfaces are representative of the target mission.

The boundary of this test

Results apply to the tested configuration. Radiation tolerance, launch qualification and the behaviour of different hardware still need their own evidence.

What would your team test?

Start with your objective. Build a mission brief around the capacity you actually need.

Explore this mission in the platform ↗

Interactive preview. Sample capacity and planning tools; live operator bookings are not connected.