Start a Project
What we do
Capabilities Services Industries
Work
Selected work Case studies
Company
About Careers Contact
Start a Project
Case study 01

A lab prototype that had to become a manufacturable instrument.

The science worked. The instrument around it did not yet exist as a product — it could not be built twice the same way, serviced in the field, or documented well enough to be used clinically.

Industry
Healthcare & medical technology
Stage at start
Working prototype
Engagement
Productization
Volvix Systems role
Architecture & embedded development
Hero photograph — the instrument on the bench
01 / The challenge

A product that exists once is not a product.

The team had spent two years proving the measurement worked. What they had was one instrument, assembled by the people who designed it, held together by knowledge that had never been written down.

They needed units that behaved identically, could be serviced by someone else, and came with the evidence a clinical setting would demand.

02 / The product

A benchtop diagnostic instrument used at the point of care. Samples are prepared and measured on the device, and the result has to be produced in minutes, by an operator who is not an engineer.

That places the demand on the whole system at once: fluid handling, sensing, timing, the operator interface and the record the instrument leaves behind.

System diagram or exploded view
FIG. 02 — SYSTEM OVERVIEW
03 / The engineering problem

Every part of the prototype assumed an expert was standing next to it.

Timing was tuned by hand for one set of hardware. Failures were recoverable only by someone who knew the internals. Nothing recorded what the instrument had actually done during a run.

The engineering problem was not the measurement. It was everything the measurement depended on, and none of it could be fixed in isolation.

04 / The approach

We kept the proven measurement path and rebuilt the system around it, in an order that let the team keep testing throughout.

01Defined the architecture — what each part of the instrument is responsible for, and what happens when it fails.02Moved timing into the system — behaviour no longer depended on one hand-tuned board.03Made the instrument explain itself — every run leaves a record, and every fault has a defined state and a message.04Designed for the technician — service access, diagnostics and calibration built in rather than improvised.05Validated against real use — repeated runs across units and operators, not a single demonstration.
05 / The result

An instrument that can be built, serviced and defended.

Units now behave the same way as each other. Faults are visible and recoverable without the original engineers. The documentation exists because the architecture produced it, not because someone wrote it afterwards.

Before
One instrument, one operator, no record.
After
Repeatable units, defined faults, traceable runs.
Now
Ready to move into controlled production.

Have a similar challenge?

Tell us what you are working on and what you need help with.

Start a Project