MedTech startups building their first medical device.

A first device needs working software and the evidence a notified body (the independent organisation that certifies a device under the EU MDR) or the FDA asks for, while the runway leaves no time to hire a software team. Our engineers develop imaging, wearable and embedded software under IEC 62304, inside your quality system, and write the software part of your 510(k) (the FDA premarket notification for a device similar to one already on the market) or MDR file. Our regulatory specialists and FDA consultants plan the route and write the submission with you.

Book a 30 minute call Write to us

Route: FDA 510(k) · EU MDR
Standards: IEC 62304 · ISO 13485 · ISO 14971
First step: Free 30 minute call with engineering

The software path

The software of a first device, step by step.

Prototype

The prototype runs, but it has no requirements, risk file or tests a reviewer would accept.

ImprovementA review shows which parts of the prototype can be kept, so working code is not written twice.

Route and plan

The regulatory route is still open, and the investors ask for the plan.

ImprovementThe development plan and the safety class are written first, and the rest of the file builds on them.

Specification and risk

The team is new to requirements, architecture and ISO 14971 risk analysis.

ImprovementRequirements and the risk analysis come before the code, and design and tests follow them, so the file shows how the device was built.

Build and verify

There are no software engineers on the team, and hiring takes longer than the runway allows.

ImprovementOur team starts within two to three weeks of signature, and every piece of code comes with its tests.

Submission

The threat model (a structured analysis of how the device could be attacked) and the SBOM (software bill of materials, the list of every software component in the build) are written at submission, when the architecture is already frozen.

ImprovementThe threat model is part of the first architecture, so the cybersecurity section is ready in time.

Release and field

After the first release, the file falls behind the code.

ImprovementEvery release goes through change control, which keeps the file up to date with the code and assesses whether the change needs a new 510(k) or a notified body notification.

The goal

A first device with a file a reviewer can read.

For the company

Software documentation prepared for notified body and FDA review
Evidence to show before the next funding round
A team that starts two to three weeks after signature

For the clinicians who use it

A new device that fits into their clinical workflow
Software verified before they use it on patients
Updates that keep the behaviour they rely on

For patients

New technology that reaches them sooner, because the software file does not hold up approval
A device whose risks were analysed and tested before its first use
Defects fixed quickly through a controlled update

Problems and solutions

What we hear, and what we do about it.

We have the funding and the timeline, but no software engineers.

A Silurus team develops the software and writes the IEC 62304 file inside your quality system. A Silurus technical lead is your single contact. The team works in your repositories and your tools, and the first engineers start within two to three weeks of signature.

Dedicated engineering teams

The prototype works, but the evidence does not exist yet.

We start with an IEC 62304 gap analysis (a review of what is missing against the standard), a three week review of the code, its tests and the SOUP (software of unknown provenance, meaning third party code used in the device) it depends on, with a written report and a remediation plan. Then we decide with you which parts become software items under IEC 62304 and which are rewritten. The same review shows what code from a previous supplier is worth before the next round.

IEC 62304 gap analysis

We have not decided between the 510(k) and the MDR.

We write the software part for both routes: the FDA software documentation at the Basic or Enhanced level, and the software part of the MDR technical documentation. Both start with the development plan and the IEC 62304 safety class (for the FDA also the documentation level), and our regulatory specialists and FDA consultants plan the route with you.

Medical software development

Our first 510(k) needs a cybersecurity section.

A cyber device needs the section 524B documentation in its first 510(k). We write the threat model with the first architecture and keep the SBOM from the first build, so the section is not written at the end.

Medical device cybersecurity

We are afraid of an open ended bill.

We quote each work package with its acceptance criteria, or each step, starting with a gap analysis. Each step is a separate contract with a written result.

How we work

Routes

What each route asks of the software, and our part in it.

Route	What the reviewer reads	Standards	Our work
FDA 510(k) or De Novo	Software documentation at the Basic or Enhanced level of the FDA guidance, and the cybersecurity section for a cyber device	FDA software guidance · section 524B	We write the software documentation and the cybersecurity section, prepare the Pre-Submission and support you through the FDA review.
EU MDR	The Annex II technical documentation	IEC 62304 · IEC 81001-5-1 · ISO 14971	We write the software part of the technical documentation, the risk management file and the cybersecurity file, and support you through the notified body review.
Both routes	Risk analysis, requirements, architecture, verification and traceability	ISO 14971 · IEC 62304	We write the requirements and the risk analysis before the code and trace them to the tests, and our regulatory specialists review the whole file before submission.

Fit

When we are the right partner.

Call us when

You have closed a funding round and want the device software built without hiring a team first
You want a research prototype turned into a product with a file prepared for regulatory review
You want regulatory specialists who plan the route and write the submission with you
You want to know what code from a previous supplier is worth before the next round

Talk to us

Tell us what you are working on.

A first device, a prototype to review or a route to plan. Write a few lines, or book a free 30 minute call with our engineers.

Book a 30 minute technical call

FAQ

Frequently asked questions.

We have no software engineers. Can you build the whole device software?

Yes. A Silurus team develops the software and writes the IEC 62304 file inside your QMS (quality management system). A Silurus technical lead is your single contact, and the team works in your repositories and your tools.

How fast can a team start after our funding round?

The first engineers can start within two to three weeks of signature. The team grows in steps when the work needs more people.

Do you support both the FDA 510(k) and the EU MDR?

Yes. We write the software part of both: the FDA software documentation at the Basic or Enhanced level with the cybersecurity section, and the software part of the MDR technical documentation.

Can we start with a defined package instead of a team?

Yes. One or two engineers who join your team, an IEC 62304 gap analysis, or a work package such as one module with acceptance criteria, each with a defined scope and a written quote. A team fits better when the roadmap runs for a year or longer.

Our prototype was built by a university group. Can we reuse it?

Parts of it, after a review. We assess the code, its tests and the SOUP it depends on. Then we decide with you which parts become software items under IEC 62304 and which are rewritten.

What does a first project cost?

The 30 minute call is free. Each step after it is quoted individually, with scope, deliverable, duration and price agreed in writing. We reply within one business day.

Related services and sectors.

Complete device software development Dedicated engineering teams Medical and dental imaging software Embedded and firmware development IEC 62304 gap analysis How we work