Blighty BoffinsWe cog your gears of innovation

prototype · open

Ground-segment prototype for a two-satellite constellation

Scheduling, telemetry and a tasking interface for two spacecraft. Boring, essential, and the difference between a constellation and a hobby.

Budget

£35–60k

Duration

18 weeks

Closes

31 Oct 2026

Background

We are building the payloads. We are not building the ground segment, and we have watched enough small operators discover in the final quarter that operating a spacecraft requires software nobody scoped.

What we need is a working prototype: pass scheduling against a ground station network, telemetry ingest and storage, a tasking interface, and enough operational tooling that two people can run two spacecraft without heroics. It does not need to scale to a hundred satellites. It needs to work reliably for two.

We would rather have something plain, well-tested and maintainable than something ambitious. The people operating this will be tired, occasionally at unsociable hours, and unforgiving of software that surprises them.

Scope

  • Design and build pass scheduling against a commercial ground station network.
  • Implement telemetry ingest, storage and a queryable history.
  • Build a tasking interface for payload operations.
  • Provide alerting for missed passes, anomalies and stale telemetry.
  • Deliver operational documentation written for a tired operator at three in the morning.

Constraints

The awkward facts, stated now rather than in week six.

  • Must integrate with a commercial ground station provider's existing interfaces
  • Two spacecraft is the design point; premature generalisation is not wanted
  • We will maintain this after handover, so the code must be maintainable by a small team
  • No bespoke hardware; this is software against existing services

Deliverables

  • Working prototype deployed in an environment we control
  • Source code under version control with a documented build and deployment process
  • Test suite covering scheduling and telemetry ingest
  • Operational runbook, written plainly
  • Two handover sessions with our operations staff

Milestones

  1. Week 3Architecture agreed and ground station interfaces confirmed
  2. Week 8Scheduling and telemetry ingest working against a test feed
  3. Week 14Tasking interface and alerting complete; operations review
  4. Week 18Handover, documentation and two training sessions

Who should apply

  • SME or university team with ground-segment or mission-operations software evidence
  • Demonstrated delivery of software that others now operate
  • Familiarity with commercial ground station network interfaces
  • Willingness to hand over maintainable code rather than a service dependency

How applications will be judged

In roughly this order.

  • Evidence of ground-segment software in operational use by a third party
  • Approach to testing, which we will weigh heavily
  • Quality of the proposed runbook approach — we will ask to see a prior example
  • Absence of any attempt to make us permanently dependent on the supplier

Terms

  • Foreground intellectual property transfers to us on final payment
  • Generic components may be retained and reused by the developer
  • Our mission parameters and payload details are confidential
  • Source code, tests and deployment process are delivered in full; no escrow arrangements

Apply

Tell the publisher who you are and what you would do. We pass it on. The rest is between grown-ups.

If your proposal includes a recurring licence fee for software we have paid to develop, we will not shortlist it.