Standards and engineering practice.
What we design toward, what we do on a typical project, and — stated plainly — what we are not.
What we design toward.
If your product has to satisfy one of these, the engineering has to be shaped around it from the first architecture decision — not audited into compliance afterwards.
Medical device software lifecycle
Governs how medical device software is planned, built, verified and maintained, and what has to be documented. If your product is in scope, this shapes the architecture from day one — it cannot be reconstructed later.
Medical device quality management
The quality system your organisation is audited against. We aim to work inside yours and produce records in the form it expects, rather than as an exception your auditor has to reconcile.
General quality management
The common baseline for industrial clients. Where you run a 9001 system, we align our process, records and handover with it.
Functional safety
Where failure has physical consequences, safety behaviour is architectural, not a feature. We design for defined failure states and work to the requirements your assessment sets.
Stated plainly: Volvix Systems is not certified or accredited under any of these, and does not claim to be. Referencing a standard means we understand what it asks of the engineering. It is not certification, approval, or a guarantee of any regulatory outcome.
Where responsibility sits: classification, conformity assessment and market approval stay with you as the manufacturer, with your notified body or auditor. We support that work; we do not replace it. Nothing here is regulatory or legal advice.
What happens on every project.
The same checklists run whether the client asked for them or not. They are the reason delivery is consistent.
Architecture written down first
The structure, the interfaces and the intended failure behaviour, written before code — something you can read and disagree with.
Code review
Changes are reviewed before they merge. Reviews look at failure behaviour, resource use and whether the next engineer will understand it — not style preferences.
Hardware bring-up checklist
Power, clocks, resets, then interfaces, in that order, before anything above them is trusted. Findings recorded against the board revision.
Test and validation
Tests written against the requirement and run against real conditions, and the results kept. Coverage is agreed per project — a prototype and a regulated instrument do not warrant the same.
Releases documented
What changed, what was tested, what is still outstanding, and how to go back.
Handover as a deliverable
Documentation, sources, build instructions and a walkthrough with your engineers, so someone else can continue the work.
How much of this a project gets is agreed with you. A two-week feasibility study and a regulated instrument do not warrant the same process, and pretending otherwise wastes your money.
This describes how we normally work, so you can judge it before engaging us. It is not a specification or a warranty, and we adapt it to what a project needs. Your signed agreement takes precedence over anything here.