pdPurpledecks
Regulated & connected · Software as a medical device (SaMD)

Medical device software development, under your quality system.

We are the senior engineers who build your medical device software to IEC 62304 and IEC 62366-1, inside your ISO 13485 quality system. We produce the software evidence your quality and regulatory people need.

Purpledecks is a senior software engineering firm based in Ireland, in the EU, working since 2012. Purpledecks develops medical device software in Ireland, in the EU: Software as a Medical Device (SaMD) and software for connected devices, built to IEC 62304 and IEC 62366-1 under your ISO 13485 quality system.

Talk to an engineer See the standards evidence →
For the founder

A senior software team that has shipped regulated, connected products. Plain answers first.

For your quality & regulatory lead

The standards evidence, mapped to what we produce and what stays yours.

For vendor risk & procurement

A firm that welcomes your qualification and audit.

PURPLEDECKS · EST. 2012 · 53.7°N 7.8°W · IRELAND · EU
§ 01 · How we think about it

Standards are evidence, not badges. We produce the software evidence your quality and regulatory people need.

A standard is not a badge you hang on a wall. It is the evidence a reviewer, an auditor or a notified body asks to see. So we do not sell you a certification. We build your software the way the standard requires, and we hand your quality and regulatory people the records, the traceability and the test evidence they need to do their job.

You keep the quality system. We work inside it, and we leave a clean evidence trail behind us. That is the whole job, and it is a rarer thing than it sounds.

§ 02 · The record

What we do, exactly. And the line we hold.

The claim · lift it whole
We build medical device software to IEC 62304 and IEC 62366-1. We work under your ISO 13485 quality system. Our software risk analysis feeds your ISO 14971 risk file. For medical devices, that work is built to withstand the scrutiny FDA, EU MDR and the MHRA bring.
Proof · reached market

We built the software for ResMed's first consumer product, and for the world-first sonar sleep tracking that shipped in SleepScore and reached market.

Proof · clinical trials

We built the original Bluetooth SDK for Fire1's implantable cardiac device, now in clinical trials.

The boundary

We are the software engineering team inside your process. We are not a notified body, a certification body or a regulatory adviser, and we say so plainly.

§ 03 · Standards → delivery → evidence

What we do, the evidence we produce, and what stays yours.

Software development for medical devices is a lifecycle, not a project, and this is the map of it. Four standards run this work. On two we produce the evidence outright. On two we contribute the software inputs, and the file itself stays yours. We do not level any of them up.

Standard
What we do in delivery
The evidence
What stays yours
IEC 62304
Software lifecycle
Build the software to a risk-based, versioned, traceable lifecycle.
Produce
Design records, requirements traceability, verification and test evidence, release records.
Release authority, and the quality system itself.
IEC 62366-1
Usability engineering
Usability engineering, user research and UX design, done by our own design team before the build.
Contribute
Use-specification inputs, use-related risk inputs, and the design evidence that feeds your usability engineering file.
The usability engineering file itself, and the formal usability evaluation.
ISO 13485
Quality management system
Work to your controlled processes, and your regulatory partner's.
Produce
Controlled documents, and inputs to your design history file or your EU technical documentation.
The quality system itself, and the regulatory process.
ISO 14971
Risk management
Software risk analysis that feeds your risk file.
Contribute
Hazard and mitigation records, software-level risk inputs.
The ISO 14971 risk management file itself.
IEC 62304 · Software lifecycleProduce
What we do

Build the software to a risk-based, versioned, traceable lifecycle.

Evidence we produce

Design records, requirements traceability, verification and test evidence, release records.

Stays yours

Release authority, and the quality system itself.

IEC 62366-1 · Usability engineeringContribute
What we do

Usability engineering, user research and UX design, done by our own design team before the build.

Evidence we contribute

Use-specification inputs, use-related risk inputs, and the design evidence that feeds your usability engineering file.

Stays yours

The usability engineering file itself, and the formal usability evaluation.

ISO 13485 · Quality management systemProduce
What we do

Work to your controlled processes, and your regulatory partner's.

Evidence we produce

Controlled documents, and inputs to your design history file or your EU technical documentation.

Stays yours

The quality system itself, and the regulatory process.

ISO 14971 · Risk managementContribute
What we do

Software risk analysis that feeds your risk file.

Evidence we contribute

Hazard and mitigation records, software-level risk inputs.

Stays yours

The ISO 14971 risk management file itself.

One for the US reader · QMSR

Since February 2026, the FDA's Quality Management System Regulation incorporates ISO 13485:2016 by reference. So working inside your ISO 13485 system now speaks to the US framework as well as the EU. It does not make ISO 13485 equal to FDA compliance. The QMSR keeps FDA-specific requirements on top.

§ 04 · How we work

Senior engineers, inside your process, in your time zone.

Design + engineering, one roof

Our own design team does the usability engineering, the user research and the UX before the build. The generalist shops in this lane do not have design in the same building, working to the usability standard. That is where IEC 62366-1 is won or lost.

Where a build needs more

Where a build needs specialist regulated expertise, device cybersecurity for one, we bring it in and manage it inside the same lifecycle. No hand-off, no gap in the evidence. We cover the SBOM and the secure-development inputs a vendor-risk reviewer checks first.

Where we are, and why it helps

Senior EU-based engineers. English-speaking, and in your time-zone overlap. We overlap your US working morning. Ireland and the EU is a trust and regulatory-proximity signal, close to the standards and regulators your product answers to. It is not a cost pitch, and we never sell it as one.

§ 05 · The proof

Built where getting it wrong is expensive.

Medtech software development on connected products, since 2012. The work is only as good as the eye behind it. We have built where the margin for error is zero, and opened and assessed more than forty codebases. That is the eye we bring to yours.

ResMed · consumer + health data · reached market

We built the software for ResMed's first consumer product, and for the world-first sonar sleep tracking that shipped in SleepScore and reached market.

The sonar science is ResMed's. We built the software.

Read the ResMed S+ case study.

Fire1 · implantable · clinical trials

We built the original Bluetooth Low Energy SDK for Fire1's implantable cardiac device, now in clinical trials.

Connected-device engineering where the margin for error is zero.

Connected-device depth

BLE, firmware integration and SDK work on connected products since 2012. That is the device depth the generalist shops in this lane do not have.

The wider record

Biometric identity work at national scale, for Safran Morpho and Idemia. National institutions as direct clients. The eye that has opened forty codebases reads yours the same way.

Not everything medical is a regulated device. We also build medical software outside the device boundary: patient platforms, peer support and the systems behind a care service. Someone Like Me, a cancer peer-support platform, is on the record.

See how the audit works → What we find when we open other people's code →
§ 06 · Common questions

Straight answers, for the reader who scans for gaps.

Three questions to ask any medical device software development company: who produces the IEC 62304 records, who owns the risk file, and what happens to the evidence when the engagement ends. The companies worth hiring answer all three without checking.

What is Software as a Medical Device (SaMD)?

SaMD is software that performs a medical function in its own right, rather than by driving a piece of hardware. Software that reads a signal and reports a clinical result is SaMD. The software inside a pump or a monitor is not: that is embedded device software. Both sit inside the same discipline here: IEC 62304 for the software lifecycle, IEC 62366-1 for the use, under your ISO 13485 quality system.

How do you know what your software has to be built to?

Your regulatory partner classifies the software and owns the regulatory strategy. We build to what that classification requires, and we produce the software evidence behind it: the IEC 62304 records, the requirements traceability, the test evidence, and the software inputs to your risk and usability files. If the classification is not settled yet, we build to the standard from day one, so nothing has to be reconstructed later. We are not a notified body, a certification body or a regulatory adviser.

Can you build AI-enabled medical devices (AIaMD)?

Software with AI in the clinical path needs two disciplines in one team: regulated device software, and engineers who have put machine learning into production. Purpledecks builds the device software to IEC 62304 and IEC 62366-1, under your ISO 13485 quality system. The same senior team works as Deep Purple AI, our sister brand, on production machine-learning systems. So the model and the device software are engineered in one place, to one lifecycle, with one evidence trail. Bring us the device and tell us where the AI sits.

Can you work under our existing quality system?

Yes. We work to your controlled processes, and your regulatory partner's. We produce controlled documents and inputs to your design history file, or your EU technical documentation. You keep the quality system. We work inside it.

Who owns the quality system, the risk file and the usability file?

You do. The ISO 13485 quality system, the ISO 14971 risk management file and the IEC 62366-1 usability engineering file are yours, and they stay in your system. We produce and contribute the software engineering evidence that feeds them.

What software evidence do you produce?

The IEC 62304 artefacts: design records, requirements traceability, verification and test evidence, and release records. Written to fit your lifecycle, not ours.

Do you replace our regulatory or quality consultant?

No. We produce the software engineering inputs and evidence that feed their work. We are not a notified body, a certification body or a regulatory adviser.

Do you welcome supplier qualification and audit?

Yes. We expect it, and we will answer your vendor-risk and security questions directly, under your process. References are available on request.

What happens after release?

Maintenance, change control under your process, and problem resolution. Software changes stay traceable and version-controlled, so your evidence keeps up with the product.

Do you handle device cybersecurity?

We do not do device cybersecurity in-house. Where a build needs it, we bring in specialist expertise and manage it inside the same lifecycle, so the security evidence lands with everything else. No hand-off, no gap.

Do you work with US and EU submissions?

Both. For the US, we work inside your ISO 13485 and QMSR-aligned system and produce the premarket software documentation. For the EU, we produce the software documentation for MDR and notified-body review. You make the submission. We produce the evidence behind it.

What does working with you look like for a funded startup with no internal quality team?

A short technical fit call first, then a scoped engagement. We build to the standard from day one. Where you have no quality system yet, we produce evidence that will slot into one as it forms, and we tell you plainly when to bring in RA or QA.

Start here

Talk to an engineer.

It starts with a short technical fit call. Your stage, the software scope, how we interface with your quality system, the evidence you will need, and the next step. A senior engineer, not a sales layer.

We answer the vendor-risk questions directly: how we interface with your QMS, our security posture, insurance, continuity, and references.

PURPLEDECKS
53.7°N 7.8°W · IRELAND
EST. 2012 · EU
hello@purpledecks.com

Best fit is a funded medtech team that needs senior software delivery inside an existing or emerging quality system. If you need a certified partner to own the quality system outright, the certified specialists serve that need, and we will tell you so.

If you need a medical device software development partner who works inside your quality system rather than owning it, that is the shape of this engagement.

Working since 2012 · Senior engineers only · No offshore hand-off · References on request
Reviewed by Brian Egan, Founder and CEO · Last reviewed 16 August 2026