Apex builds satellites on an in-house operating system called Octopus. I haven't seen it — nobody outside the company has.
This is my version of it.
Not a redesign of their software, which would be a guess. My own answer to the same problem, built and running rather than described.
A working prototype of build execution for spacecraft manufacturing — the traveler a technician works from at the bench, and the board a planner watches. Built to be used, not presented: it runs, it measures itself, and the two surfaces share one design system.
Same diameter, same finish, half the stack. Indistinguishable in a gloved hand.
White is the part in your hand right now. Green is placed.
The part the bolt pattern above sits on. Eight fasteners on the bolt circle, the clevis lug and pin bore, seated against the panel rail — the same joint the technician is torquing.
Live screens from the prototype. Product palette shown as designed — status colour is a reserved vocabulary inside the product and does not borrow the studio's accent.
A consumer app that wastes four seconds annoys someone. A work instruction that wastes four seconds does it across every step, every unit, every technician, every shift. The multiplier is the entire point — and it applies to error as much as to time. An ambiguous screen doesn't just slow a build, it produces scrap.
The specific failure this study goes after is the one that happens before any work starts: a technician takes a kit to the bench and the kit is wrong. Two counts short, or — worse — the right count of the wrong part. On paper that's caught by someone counting against a printed list, which is to say it is often not caught at all.
A technician is standing, gloved, mid-task, holding hardware, reading one line at a time from a mounted tablet at arm's length. A planner is seated, scanning twenty rows for the one that's slipping. Designing for one and letting the other inherit it is how internal tools usually go wrong.
So the system carries one set of semantic tokens and swaps only density and contrast. Same components, same colours, same rules — a 64px control on the floor and a 40px control at the desk, from the same declaration. It survives a phone too, because the person evaluating it will open it on one.
Green, amber and red mean go, hold and stop — and nothing else. No brand accent, no chart series, no decorative highlight may borrow them. A colour that means two things on a factory floor means nothing.
Raising a non-conformance is one tap with a reason code. Signing a buy-off into the permanent build record is a deliberate 1.2-second hold. If reporting a problem is harder than ignoring one, you get clean data and bad hardware.
The traveler has always listed the torque order and the washer stack-up. Enforcing them is different work: a wrong pull is caught at the wrench in the second it happens, instead of at buy-off two hours later when the fix is rework.
One step per screen, a fixed status rail above and a fixed commit rail below. Steps publish their action into that rail rather than rendering buttons inside scrolling content — so growing the content can never push the action off screen.
When the kit check fails, the screen says what's wrong and offers the two people who can fix it: the supply runner, and the bay lead who needs to know a sealed kit went out wrong. A dead end sends the technician walking, which is the behaviour the product exists to remove.
Part numbers get read aloud, written on a card, and typed into another system. NAS1149D0463K against NAS1149D0332K is a scrap event; proportional type makes that comparison harder for no benefit.
The kit check isn't a fresh invention for this prototype. I designed a similar product for a pitch at SpaceX — an iPad tool for technicians working on the vehicle that photographs the fixture, confirms the correct bolts and nuts are actually in the technician's hand, and alerts a supply person when they aren't.
Bench takes that design further — and building it running is what surfaced the parts the pitch had not had to answer. What happens when the count is right but the part is wrong. Who else needs to know that a sealed kit went out bad. What the screen does while the runner is still walking. A proposal can stay abstract about the failure case; a prototype cannot.
This prototype was built from the outside. With real access, the first thirty days go to earning the right to change anything — and two questions do most of the work.
Every floor has a clipboard, a whiteboard, or a group chat doing a job the software failed at. Those artefacts are the backlog, already prioritised by the people who felt the pain.
The moment a technician walks to a supervisor instead of tapping the button is the highest-value defect in the system, and it never appears in a ticket.
Beyond that: shadow a full shift per role before proposing anything, sit with quality on non-conformance dispositions, and watch a shift handover — handovers are where the real information model is visible, because that's when people say out loud what the system failed to carry.
The prototype instruments itself: every tap and the time on each step, including taps that turn out to be mistakes — because the claim being tested is “fewer taps to finish the job,” not “fewer taps on the happy path.”
| Measure | Why it's the right one | Read it as |
|---|---|---|
| Task time per step | The multiplier that makes internal tools worth designing at all | Median, not mean — the tail is where the pain is |
| Defect escape rate | Errors caught at the wrench versus at buy-off or later | Moving catches earlier is the whole thesis |
| Blocked-time to resolution | How long a technician waits between finding a problem and someone acting | The floor-to-supply loop, in minutes |
| Voluntary reporting rate | Whether people raise non-conformances at all | If this falls, the other three are lies |
Every colour and type size comes from one token file. No component contains an arbitrary font size or a raw hex value — and that's enforced rather than requested. A precommit guard reads the staged diff and rejects new arbitrary values, with a ratchet so existing debt pays itself down instead of blocking a shipping team.
It caught three violations in my own code while I was building this, which is the argument for it. A design system that only lives in a library file is a suggestion. This one fails the commit.
$ npm run guard
components/StepView.tsx
✕ arbitrary font-size — use a named text-* token
✕ raw hex — use a color token
2 new violations. Commit blocked.
The comparison on the summary screen uses an illustrative baseline for the paper-traveler flow. I don't have anyone's floor data, and an invented number would be worth less than no number — the point is that the instrumentation exists, so the real figure is a week of logging away rather than a research project.
The kit check simulates its vision result. Classifying fasteners against a known bill of materials with a fixed camera and a controlled background is tractable, but it isn't solved here — and the design argument deliberately doesn't depend on it. The same screen holds up with a barcode scan or a counting scale behind it.
And it was designed without users. Every claim in it is a hypothesis with a way to be measured, which is the most an outsider should assert.
Bryan S. Holland — Automatic Delight. Twenty years designing the interaction layer where errors carry real consequences.
Bench is an unsolicited concept study. It is not affiliated with, endorsed by, or built from the internal software of any company, and contains no proprietary information — every part number, torque value, work order and serial in it is invented. Built with Next.js 16, React 19 and Tailwind v4, with no component library.