Software development for medical device makers
We take on medical device software development for manufacturers who need an engineering partner that works inside their quality system. That covers companion apps and device software, the tooling around the design history file, and AI that helps quality and regulatory teams keep up with post-market work.
Where the work gets stuck.
Documentation outgrows the team
MDR and IVDR technical files, risk files and design history grow with every release. Engineers spend weeks updating traceability between requirements, risks and tests by hand.
Post-market signals are scattered
Complaints, service reports, device logs and literature arrive through different channels. Spotting a trend or a potential serious incident depends on people reading everything in time.
Software partners that know the process are scarce
Few development shops have worked with software safety classification, SOUP management and design reviews. Manufacturers end up rewriting documentation after the code is done.
How we improve medical devices.
Each one is scoped around your systems and rules, and each one keeps a person in charge of the decisions that matter.
Companion apps and device software
We build patient and clinician apps, device dashboards and cloud back ends following your software development plan under IEC 62304. Your quality and regulatory leads approve design inputs, reviews and releases.
Traceability and design control tools
An internal tool links requirements, hazards, risk controls and test results across Jira, Polarion or Jama, and flags gaps before a design review. Engineers resolve the gaps and the tool regenerates the trace matrix.
Technical file assistant
Regulatory and quality staff search the technical documentation, clinical evaluation and notified body correspondence, with answers cited to the controlled source. It speeds up audit preparation and responses to questions.
Complaint intake and triage
Complaints from service, sales and customers are read, classified and matched to similar past events, with possible reportable incidents flagged. A quality engineer makes the vigilance assessment and records the decision.
Post-market surveillance data
Device telemetry, service records and complaint data are brought into one pipeline for trending and periodic safety reporting. The PMS team works from data that is refreshed daily.
Roadmap for AI in your device
For manufacturers planning AI features, we map intended use, likely classification under the MDR and the AI Act, and the data and evidence each option needs. Your regulatory lead uses it to decide what to pursue.
Built around the rules.
What we design for from the first week. Your legal and compliance people keep the final word.
MDR and IVDR
We produce software documentation that fits into your technical file under the MDR or IVDR, and support your team during notified body questions. Classification and conformity decisions stay with the manufacturer.
IEC 62304 and ISO 14971
Development follows your software safety class, with architecture, SOUP lists, unit and integration testing and problem resolution handled as the standard expects. Risk controls are traced to ISO 14971 risk files.
ISO 13485 quality system
We work under your QMS as a controlled supplier, using your procedures, templates and review gates. Supplier agreements and audits are set up at the start of the engagement.
EU AI Act and cybersecurity
AI in a device that needs notified body assessment counts as high-risk under the AI Act, which adds data governance and logging duties. We also design for security in line with IEC 81001-5-1 and MDCG cybersecurity guidance.
Works with what you run.
If a system has an API, a database, an export or an inbox, we can build on it. These are the ones we meet most.
- Jira and Confluence
- Polarion
- Jama Connect
- Codebeamer
- Greenlight Guru
- Salesforce Service Cloud
- SAP
- EUDAMED
- AWS IoT Core and Azure IoT Hub
Where to start.
Automated trace matrix for one product
A tool that pulls requirements, risks and test results for one product line and produces a trace matrix with gaps highlighted. It relieves engineers before the next design review and shows how we work within your QMS.
Talk it throughWhat it includes
- Connectors to your ALM and test tools
- Gap and orphan detection rules
- Exportable trace matrix for the DHF
- Tool validation evidence for your QMS
Guides.
Build vs buy software: a decision guide for operations and product teams
A practical guide to choosing between off-the-shelf and custom software, with a cost comparison, a decision matrix and a checklist for your team.
10 min read
AI vendor security questionnaire: what to ask before you buy or build
The questions to ask an AI vendor, or your own team, about data, model providers, access, logging, quality, incidents, GDPR and exit, and how to score the answers.
8 min read
Further reading.
Agentic engineering: how to ship SaaS faster with coding agents
How senior engineers use coding agents to ship SaaS faster while keeping control of architecture, quality and security.
4 min read
How to evaluate RAG: retrieval metrics, faithfulness and golden sets
How to measure a RAG system properly: separate retrieval from answers, check faithfulness claim by claim and build a golden set you can trust.
4 min read
LLM evals: how to test AI features before every release
A practical approach to LLM evals: build a test set from real cases, combine code checks with model grading, and block releases that regress.
5 min read
Common questions.
Yes. We follow your software development plan, procedures and templates and take part in design reviews. You qualify us as a supplier and audit us like any other critical vendor.
We build the software and the documentation that IEC 62304 requires for its safety class. As the legal manufacturer, you own the intended use, classification and CE marking, and we support those decisions with evidence.
Yes, when the AI supports the process and a qualified person makes each vigilance assessment within the reporting timelines. We log every suggestion and decision so auditors can follow the trail.
We keep a maintained SOUP list with versions, known anomalies and the rationale for each component, and track security advisories. The list is delivered as part of the software documentation.