From idea to market: medical device software development roadmap

Medical device software development, from idea to market, typically takes 18–36 months if the product is a Class IIa medical device or higher. That time is spent not only on coding but also on confirming the class, building a quality system, documenting requirements and risks, gathering clinical evidence and having a notified body review all of it before CE marking.

This guide addresses the questions in the order they arise, with our estimates for time and cost. The figures are bon.do’s own estimates from projects and quotes, not guarantees.

How long does it take to bring medical software to market?

A focused MVP takes 2–4 months, a regulated app with validation takes 6–12 months, and bringing Class IIa software from idea to CE marking typically takes 18–36 months. The notified body review comes on top of development and depends on the body’s capacity. According to Team-NB’s May 2026 survey, the review itself typically takes 13–18 months.

The stages overlap. The quality system and the technical documentation are built alongside the software, not afterwards.

Is your software a medical device?

Your software is a medical device if you, as the manufacturer, intend it to diagnose, prevent, monitor, predict or treat disease in individual patients. The intended purpose determines whether the software is a medical device, not the technology. This is the most important question in the roadmap, because the answer drives time, cost and what you need from a partner.

The class follows from Rule 11 in Annex VIII of the Medical Device Regulation (EU) 2017/745:

In vitro diagnostic software is classified under the IVDR. Use MDCG 2019-11 rev.1, revised in June 2025, and your national competent authority’s guidance; in Denmark that is the Danish Medicines Agency (Lægemiddelstyrelsen). If you are unsure, have the class assessed early by a regulatory consultant or a notified body. If the software is not a medical device, GDPR for health data still applies when it processes health data. If the product uses AI, the EU AI Act can apply on top of the MDR; see our guide to AI in a medical device.

Stage 1: validate the problem before you write code

Before the first line of code you need to know that you are solving a real problem for someone who will pay. Dropping an idea now costs less than dropping it after an MVP.

• The problem. What specific problem do clinicians, patients or researchers have? How often does it occur, how serious is it, and what do they currently use to address it?
• The users. Interview clinicians, observe the workflow and write down the user needs. These user needs inform the requirements and the usability file.
• The market. Who buys? In Denmark it is often the regions through public tenders, and the decision involves clinicians, IT, procurement and finance. Size the market from real buyer budgets, not from a count of users.
• The class. Make a preliminary classification using the Rule 11 table in the section on whether your software is a medical device. It shapes the rest of the plan.

Hospital and regional innovation units are a good route to clinicians who want to test an idea.

Stage 2: prototype and requirements

A clickable prototype shows whether clinicians understand the product before you invest time in development. Build it in a tool such as Figma and test it with 5–8 users from the target group. That is formative usability under IEC 62366-1, and the results must be documented if the product is a medical device.

Write the requirements down at the same time:

• User requirements from stage 1, for example “As a cardiologist I want to see the patient’s trend so that I can adjust treatment.”
• Functional and non-functional requirements: performance, security, accessibility (WCAG 2.2 AA is a good target).
• Regulatory requirements, if the product is a medical device.

Technology choices have regulatory consequences too. Libraries and frameworks are SOUP (Software of Unknown Provenance) under IEC 62304 and must be listed, assessed and kept up to date. Choose well-supported tools and EU hosting if you process health data.

Stage 3: an MVP with the quality system in place

An MVP in life science is the smallest version that can prove the clinical or business value, built so that it can become the regulated product. “Move fast and break things” does not work when patient safety is at stake, but short iterations with documentation do.

If the product is a medical device, the quality system must be in place from the start:

• Design controls under ISO 13485: input, output, verification and validation.
• The software life cycle under IEC 62304 and risk management under ISO 14971.
• Traceability from user needs through requirements and risks to tests.
• Change control, so every release can be explained.

Agile development and regulation fit well together when the definition of done includes documentation and tests run automatically in continuous integration (CI).

Note that an MVP without a CE mark may not be used for a medical purpose on patients outside a clinical investigation. In Denmark a clinical investigation needs approval from the Danish Medicines Agency and an ethics review. Usability tests and tests with synthetic data can be done without one.

Stage 4: technical documentation and CE marking

CE marking medical device software requires technical documentation under MDR Annexes II and III and, for Class IIa and above, an assessment by a notified body. The documentation describes the product, the design, risk management, verification and validation, the clinical evaluation and the instructions for use.

Validation typically includes:

• A validation plan and report with test results.
• A traceability matrix from requirements to tests.
• A summative usability evaluation.
• A clinical evaluation showing the product delivers the clinical benefit you claim.

You choose the notified body yourself. Well-known bodies designated under the MDR include TÜV SÜD, BSI, DNV, SGS and DEKRA. Always check in the EU NANDO database that the body is designated for your type of device. Notified body capacity is limited, so make contact early. An MDR certificate is valid for up to five years.

What does medical device software development cost?

At bon.do a focused MVP typically lands at DKK 30,000–150,000, and a complex or regulated platform from DKK 250,000, delivered in phases, as listed on our pricing page. Those figures cover development. Regulatory costs are additional and vary considerably by class and product.

See also our guide to what an app costs.

How do you fund medical software in Denmark?

Most life science startups fund the journey with a mix of public money and private capital. Tie funding rounds to regulatory milestones, such as classification, MVP and CE mark, so investors can see what the money buys.

• Innovation Fund Denmark (Innovationsfonden): According to the fund, InnoBooster supports development projects in small and medium-sized companies with DKK 200,000 to 5 million, covering up to 35% of the project costs.
• EIFO (Export and Investment Fund of Denmark): The former Vækstfonden has been part of EIFO since 2023, offering loans and co-investment.
• EU: The EIC Accelerator under Horizon Europe supports deep tech companies with grants and equity.
• Private investors: Business angels and Nordic venture funds focused on health and medtech.

Always check each programme’s current calls for applications and funding amounts.

Launch and operation after the CE mark

The CE mark gives access to the EU and EEA market, but the work does not stop at launch. As the manufacturer you must run post-market surveillance, report serious incidents to the competent authority and, for Class IIa and above, write periodic safety update reports.

• Pilot sites. Start with two or three clinics or departments, train the users well and collect data on use and errors.
• Sales. Selling to public healthcare organisations often involves tenders, so plan for long sales cycles.
• Expansion. The Nordic countries are a natural next step. The US requires separate FDA clearance or approval.

How to choose a development partner

Choose a development partner by assessing its medical software experience, quality processes, ownership terms and post-launch support. Most life science startups do not have a full software team from the start, so this choice determines how flexible the roadmap will be later. Ask:

• Which medical software projects have you delivered, and can we talk to those clients?
• How do you work with IEC 62304, ISO 14971 and your own or our quality system?
• What do you deliver for the technical documentation?
• How do you handle change control and validation?
• Who owns the code, the data and the documentation? Read more about software ownership.
• What happens after launch: operation, updates and support?

What bon.do does

We are a software company in Svendborg, Denmark, building regulated apps, platforms and connected devices. Kirsten has more than ten years of experience in pharmaceutical quality assurance, and Morten has more than 22 years of experience building software. Among other projects, we built the backend for a CE-marked medical device, where every result can be traced back to the raw measurement.

With us you own the code, the data and the IP from day one. We work to ISO 13485 principles and deliver the documentation your technical file needs.

Next step

Start with two things: confirm the class, and describe the smallest product that can prove the value. If you want help with both, book a free project assessment. You get a practical roadmap, an overview of the risks and a written price estimate, with no obligation.