System architecture and technology selection

The decisions made in the first three weeks of a programme determine what it costs for the next five years. Most of the expensive problems we are called in to fix were designed in before anyone wrote a line of flight code.

The advisory offer is abstract. This makes it concrete.

Why this is the work that matters

A wrong autopilot choice is recoverable. A wrong bus topology is not, and neither is a sensor whose supply dries up in year two. Those surface during integration, when the schedule has no slack left and changing direction costs programme years.

We are regularly engaged for nothing else: no hardware, no firmware, just the architecture and the technology selection behind it. Clients come to us because the alternative — discovering the answer empirically — is the most expensive way to learn it.

What an architecture engagement covers

  • Requirements interrogation. What the system must actually do, separated from what the specification currently says. These differ more often than not.
  • Trade studies with numbers. Candidate architectures scored against mass, power, thermal envelope and certification path — not against preference.
  • Component and supplier selection. Including second sources, end-of-life exposure and what each part does at the edges of its rating rather than in the middle.
  • Failure analysis before build. What breaks, how it is detected, and what the system does next.
  • A written architecture your team can build from — interfaces, budgets, and the reasoning behind each choice, so the decisions survive the people who made them.

Why our advice is worth more than an opinion

We distribute thousands of components a month and have done for ten years. That is not a side business that happens to sit next to the engineering — it is the evidence base underneath it. We see which parts come back, and which second sources are real rather than promised.

We are also the first users of everything we sell. A part we recommend is a part we have flown, instrumented, and in several cases stopped using. That is a narrower catalogue than a distributor would normally carry, and deliberately so.

What you get

  • A decision you can defend to a customer, an auditor or a certification body
  • Known end-of-life exposure before it becomes a redesign
  • An integration phase with no architectural surprises left in it

Talk to us about your system

The most useful first message describes the constraint you cannot get past.

Start a conversation