Bon.do · Insights

How much does an app cost in Denmark? Prices for 2026

info@bon.do (Morten Bondo Vraa) — Tue, 18 Nov 2025 00:00:00 GMT

“What does an app cost?” is the question we hear most. The honest answer is a range, not a number, but the range is narrower than most guides suggest. This guide sets out the prices bon.do actually quotes, the factors that move them, and the running costs that come after launch.

How much does an app cost in Denmark?

With bon.do, a focused first version of an app (MVP) typically costs DKK 30,000–150,000 and takes 2–4 months, covering UX and design, iOS, Android and/or web, the backend, hosting set-up and the store release. A complex or enterprise platform with many roles, integrations, devices or regulatory requirements typically costs from DKK 250,000 and is delivered in phases, each with its own scope and price. A regulated medical or life science app takes 6–12 months including validation and is estimated per project. Later work on an existing app is billed at DKK 800 per hour for an ad hoc senior developer. These are bon.do’s own price ranges, the same ones on our pricing page. Other Danish agencies publish different numbers, so compare full quotes on the same scope rather than headline figures.

Type of product	What it usually includes	Typical timeline	Typical price (bon.do)
MVP app or platform	UX and design, iOS, Android and/or web, backend, hosting set-up, store release	2–4 months	DKK 30,000–150,000
Typical app	An MVP plus more roles, integrations and features	3–6 months	Estimated per project
Regulated app	Medical or life science software with validation and documentation	6–12 months, incl. validation	Estimated per project
Complex or enterprise platform	Multi-platform, multi-tenant, integrations, IoT and device software	Phased	From DKK 250,000

Smaller, well-defined tasks are possible too: our fixed-price projects start from DKK 10,000.

What makes an app more or less expensive?

The main cost drivers are platforms, integrations, roles and data, design, documentation and post-launch work. These usually shape the first conversation with a client.

Platforms. iOS, Android, web, or all three. One shared codebase costs less than separate apps.
Integrations. Every system, device or partner the product talks to adds design, build and test work. Payment services, login providers, patient records and hardware are common examples.
Roles and data. More user types and permissions mean more screens and rules. Sensitive data, such as health data, means more security and privacy work.
Design depth. A clean standard interface is cheaper than a fully custom experience with animation and custom components.
Documentation. Regulated products need validation and traceable evidence. That work should appear as a separate line item in the estimate.
After launch. Hosting, support and the roadmap beyond version one. These are not part of the build price but belong in the budget.

The cheapest way to influence all six is to cut scope: launch with the one workflow that proves the product, then add features based on actual usage.

Native or cross-platform: which is cheaper?

Cross-platform is usually cheaper. With Flutter or React Native, iOS and Android share one codebase, so most features are built, tested and maintained once instead of twice. Native development (Swift for iOS, Kotlin for Android) means two codebases and roughly two implementations of the app itself.

Native is still the right choice in some cases:

heavy graphics, 3D, AR or VR
deep use of device hardware or the newest platform features on day one
an organisation that already runs separate iOS and Android teams

For most business, health and service apps, cross-platform performance is close enough to native that users do not notice. We build most of our apps in Flutter for that reason. A web app or PWA is cheaper again, but has less access to device features and no regular store presence.

What does an app cost to run and maintain?

An app costs money every year after launch: store fees, payment fees, hosting, monitoring, maintenance, support and compliance. The fixed store fees are small: Apple’s developer program costs USD 99 per year and a Google Play developer account USD 25 once. Payment fees grow with revenue; Stripe charges 1.5% + DKK 1.80 per standard EEA card payment in Denmark. Hosting depends more on the architecture than on the number of users: when we rebuilt the MindPlus app, a simpler architecture lowered its monthly hosting and service costs. Maintenance is often the largest running cost, because OS updates, security patches and library updates never stop, and a regulated app costs more to maintain because every release must be validated and documented. Budget for these running costs alongside the build price before you commit.

Cost	What to expect
Apple Developer Program	USD 99 per year, or the local-currency price where Apple offers one (Apple)
Google Play developer account	USD 25, one-time (Google)
Store commission on digital sales	Apple and Google take a commission on paid apps, in-app purchases and subscriptions. Apple’s Small Business Program is 15% (Apple); Google Play’s rates depend on region, revenue and product type (Google). The EU terms have changed in recent years, so check the current ones.
Card payments via Stripe in Denmark	1.5% + DKK 1.80 per standard EEA card payment, higher for UK and international cards (Stripe)
Hosting and monitoring	Depends on the architecture more than on the number of users. When we rebuilt MindPlus, a leaner architecture lowered the monthly hosting and service cost (case).
Maintenance	OS updates, security patches, library updates and small fixes. A common industry rule of thumb is 15–25% of the build cost per year, but it is not based on independent research. We estimate service agreements from the product’s actual needs, and a regulated product can cost more to maintain, because every release has to be validated and documented.
Support and compliance	Your own support time, and for regulated products post-market activities and audits.

One more point on hosting: GDPR does not require you to host in the EU. Transfers outside the EU and EEA are allowed when they meet the rules in Chapter V of the GDPR. For health data, most of our clients still choose EU regions because it keeps the compliance work simpler. Read more in our guide to GDPR and medical data.

What does a regulated or medical app cost?

A regulated app costs more and takes longer, because the documentation is part of the product. In our experience a regulated app takes 6–12 months including validation, and we price the regulatory work as separate line items in the estimate rather than adding a flat percentage.

Depending on the classification, the extra work typically covers:

a quality management system or work inside the client’s QMS, often aligned with ISO 13485
software life-cycle documentation under IEC 62304
risk management under ISO 14971
verification, validation and traceability from requirement to test
usability engineering and accessibility; we design to WCAG 2.2 AA, the current W3C recommendation (W3C)
the technical documentation needed for CE marking, and involvement of a notified body if the class requires one

Notified body fees, clinical evaluation and insurance vary a lot by device class and supplier. Ask the notified body and your insurer directly rather than relying on a general figure. Our guide from idea to market in life science walks through the steps.

Hourly rate or fixed price?

A fixed price suits an app with a well-defined scope, and hourly billing suits ongoing development. At bon.do, a defined MVP gets a fixed written estimate in the DKK 30,000–150,000 range, larger platforms from DKK 250,000 are split into phases with their own scope, price and acceptance criteria, an ad hoc senior developer costs DKK 800 per hour, and a dedicated team starts from DKK 400 per hour with a minimum of three months. When you compare offers from app developers, compare the total price for the same scope, not the hourly rate. A low hourly rate combined with a high estimate of hours, or an estimate that leaves out testing, documentation or the store release, is not cheaper. Every project starts with a free project assessment that ends in a written estimate, so you know the price before development begins.

Fixed price. Best for a defined MVP. You know the price before you start, and changes are handled as explicit change requests.
Phased plan. Best for larger platforms. Each phase has its own scope, price and acceptance criteria.
Hourly. Best for ongoing development on an existing product. At bon.do, an ad hoc senior developer is DKK 800 per hour.
Dedicated team. Best for a long roadmap. Our teams start from DKK 400 per hour with a minimum of three months.

How to keep the price down without cutting corners

The most effective way to keep the price of an app down is to cut scope and avoid rework, not to cut quality:

Start with an MVP that solves one problem for one group of users.
Choose cross-platform unless you have a specific reason for native.
Use proven, open tools and standard components before building custom ones.
Automate tests from the start, so later changes stay cheap.
Plan the regulatory work from day one; retrofitting documentation is slower than writing it along the way.
Own your code, data and accounts, so you can change supplier without starting over. Our guide to software ownership has a checklist.

How bon.do estimates your app

Every project starts with a free project assessment, which typically takes 1–2 weeks. We define what you want to build, identify the risks and map out the fastest safe route to delivery. You get:

the scope and requirements
a concrete roadmap
an architecture and risk overview
a transparent, written price estimate

The assessment is without obligation. If we are not the right fit, you can take the material to another team. All code, data and IP are yours from day one.

If you are budgeting for an app, book a free assessment and we will give you a written estimate for your product.

From idea to market: medical device software development roadmap

info@bon.do (Morten Bondo Vraa) — Sun, 05 Oct 2025 00:00:00 GMT

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.

Stage	Typical duration	Outcome
1. Validate the problem and the class	1–3 months	User needs, market, preliminary classification
2. Prototype and requirements	1–3 months	Clickable prototype, formative usability, requirements
3. MVP with a quality system	2–4 months	First version, ready for testing and investigation
4. Regulated version and validation	6–12 months	Verified and validated software, technical documentation
5. Notified body and CE mark	Several months to over a year	Certificate and CE marking
6. Launch and operation	Ongoing	Post-market surveillance, updates

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:

What the software does	Class	Notified body
Provides information for diagnostic or therapeutic decisions	IIa, or IIb/III if a wrong decision can cause serious deterioration or death	Yes
Monitors physiological processes	IIa, or IIb for vital parameters where changes can cause immediate danger	Yes
All other medical software	I	No, the manufacturer self-declares

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.

Item	What drives the cost
Development	Platforms, integrations, roles, documentation requirements
Quality system	Whether you build it in-house or with a consultant, and whether it is certified to ISO 13485
Clinical evaluation	Whether literature and existing data are enough, or a clinical investigation is needed
Notified body	The body’s fees for assessment and annual audits. Get quotes from several

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.

GDPR and health data: processing patient data lawfully in Denmark

info@bon.do (Morten Bondo Vraa) — Sat, 30 Aug 2025 00:00:00 GMT

According to Article 9 of the GDPR, health data is special category data, and processing it is prohibited unless you have both an Article 6 legal basis and an Article 9 exception. On top of that you usually need a data protection impact assessment (DPIA), security that matches the risk, and a way to report a breach within 72 hours. This guide walks through the requirements in the order they tend to come up when you build a health app, a patient portal or a medical system in Denmark.

This guide draws on our experience in our own projects. We are software engineers, not lawyers, so use this guide to ask the right questions and have your data protection adviser confirm the answers.

Health data is any information about a person’s physical or mental health, including information about healthcare services that reveals something about their health status (GDPR Article 4(15)). It covers far more than medical records.

In practice, this is almost always health data:

Diagnoses, symptoms, medication and treatment history
Readings from medical devices and sensors, such as heart rate, VO₂max or blood glucose
Wearable data, when it is used to assess health
Appointments with a doctor or a psychologist, because they reveal that the person is in treatment
Combinations of data that together say something about health

Genetic and biometric data are special categories too and are subject to the same strict rules.

Which legal basis should you use for health data?

You need two things: an Article 6 legal basis and an exception to the prohibition in Article 9(2). According to the Court of Justice in case C-667/21, processing based on an Article 9 exception must also satisfy at least one Article 6 legal basis, so the exception cannot stand on its own. Legitimate interests is not an Article 9 exception.

Article 9(2) exception	Typical use	Condition
(a) explicit consent	Health apps people choose for themselves	Consent must be explicit and can be withdrawn
(h) healthcare	Clinics, hospitals, record systems	Based on law or a contract with a health professional, and processed under professional secrecy (Article 9(3))
(i) public health	For example infectious disease surveillance	Needs a basis in EU or national law
(j) research and statistics	Research databases	Needs a legal basis and appropriate safeguards

The most common mistake we see is a health app that relies on “healthcare” when no health professional bound by secrecy is involved. In that case, point (h) does not apply, and the basis is usually explicit consent. If you supply the software to a clinic, the clinic is usually the controller and you are the processor.

When does health data require a DPIA?

A DPIA is required when the processing is likely to result in a high risk to the people concerned (Article 35). Large-scale processing of special category data is explicitly listed in Article 35(3), and Datatilsynet has published a list of processing activities that always require an impact assessment. Check it before you decide you can skip one.

A useful DPIA contains:

A description of the data flow: which data, from whom, to whom and for how long
An assessment of necessity and proportionality
The risks to patients, scored by likelihood and impact
The measures that reduce those risks
A conclusion on the residual risk

If the assessment shows a high residual risk that you cannot reduce, you must consult Datatilsynet before processing starts (prior consultation under Article 36). Datatilsynet does not approve a DPIA. It can advise and, in the end, ban or restrict the processing.

Valid consent is freely given, specific, informed and unambiguous (Article 4(11)), and Article 7 requires that you can prove it and that withdrawing it is as easy as giving it. For health data the consent must also be explicit (Article 9(2)(a)).

In the product that means:

An active choice, such as an unticked box, with wording that names health data
Separate consent for treatment, research and marketing, never bundled
A consent record with the time, the exact wording and the version the user saw
A clearly visible option to withdraw consent and stop the processing immediately
Deletion when consent was the only basis and no other obligation requires retention

When an information society service based on consent is offered directly to children, the age limit in Denmark is 13 (Article 8 and the Danish Data Protection Act). Below 13 you need parental consent and must make reasonable efforts to verify it.

Which security requirements apply to patient data?

GDPR Article 32 requires security appropriate to the risk, but the law names no specific algorithms, password lengths or recovery times. You set those in your risk assessment and document them.

This is our starting point for health data, not a legal requirement:

Encryption: TLS for all traffic and encryption of databases, files and backups, with keys in a separate key vault
Access: role-based access with least privilege, and MFA for healthcare staff
Login: MitID for citizens and MitID Erhverv for staff when the solution needs national identity
Logging: a tamper-resistant log of reads, changes and deletions of patient data, kept for a period you can justify
Operations: backups tested by restoring them, and recovery targets (RTO and RPO) that fit the clinical use
Testing and development: pseudonymised or synthetic data instead of real patient data

In the Wear & Care platform, access is scoped to the individual care home, login runs through MitID and NemLog-in via Keycloak, and every event is logged. In the backend we built for a CE-marked medical device, secrets live in Azure Key Vault, and services use Managed Identity instead of passwords in configuration.

How long should patient data be kept?

As long as the purpose requires and no longer (Article 5(1)(e)), unless another law requires longer retention. For patient records it does: according to the Danish executive order on authorised health professionals’ patient records (BEK no. 1361 of 24 November 2025, section 35), doctors and dentists, among others, must keep records for at least 10 years.

The right to erasure (Article 17) does not apply while retention is a legal obligation. So build the retention rules into the data model: every data type needs a defined retention period, an owner and automatic deletion or anonymisation when that period ends.

Can health data be stored with a US cloud provider?

Yes, if the transfer has a valid basis under GDPR Chapter V. Within the EU and EEA there are no extra requirements. Data can go to countries with an adequacy decision without further safeguards.

United States: the EU-US Data Privacy Framework is an adequacy decision for certified US companies. The General Court upheld it on 3 September 2025 (Latombe, T-553/23), but the ruling has been appealed to the Court of Justice (C-703/25 P) and the case is still pending. Have a plan B.
Other third countries: use an Article 46 safeguard, usually the EU standard contractual clauses or binding corporate rules, and carry out a transfer impact assessment (TIA) for every transfer that relies on them.
Remote access counts: access to the data by support staff in a third country also constitutes a transfer, even if the data sits in an EU region. Datatilsynet’s cloud guidance from March 2022 sets out what to check, including support access from third countries.

What must a data processing agreement contain?

Article 28 requires a written agreement with every processor. At a minimum it covers:

Purpose, duration, types of data and categories of data subjects
The requirement for the processor to act only on instructions
Security measures and assistance with breaches
Rules for sub-processors, including approval and transfers
Assistance with data subject rights and with the DPIA
Deletion or return of data at the end
The right to audit and inspect

Datatilsynet publishes a standard template for data processing agreements, which is a good starting point.

What happens when health data is breached?

You must report a breach to Datatilsynet within 72 hours of becoming aware of it, unless it is unlikely to result in a risk (Article 33). If it is likely to result in a high risk, patients must also be told without undue delay (Article 34). Every breach goes in your internal register, including those you do not report.

The Article 83 ceiling is EUR 20 million or 4% of global annual turnover, whichever is higher. In Denmark, Datatilsynet cannot issue fines itself. It recommends a fine and reports the case to the police, and the courts set the fine under section 41 of the Danish Data Protection Act. Datatilsynet can still issue criticism, orders and bans on its own.

In Denmark, health software must also follow the Health Act, the executive order on patient records and the Data Protection Act, fit into the national infrastructure, and prepare for the European Health Data Space from 2027:

The Health Act (Sundhedsloven): professional secrecy, the patient’s right of access to their own record, and rules on disclosing health information
The executive order on patient records: requirements for the content, access and retention of patient records
The Data Protection Act (Databeskyttelsesloven): the Danish supplementary rules, such as the age limit for children and the rules on fines
National systems: MedCom messaging standards, the Shared Medication Record (FMK), MitID and MitID Erhverv, and regional systems such as Sundhedsplatformen in the Capital Region and Region Zealand
European Health Data Space: Regulation (EU) 2025/327 applies generally from 26 March 2027, with later deadlines for electronic health record systems and the secondary use of health data from 2029

We are usually the processor for a manufacturer, a clinic or a municipality. We supply the technical input to your DPIA and data processing agreement: data flow, hosting, sub-processors, access model and logging. The legal assessment stays with you and your adviser. If the product also diagnoses or monitors patients, check first whether your software is a medical device, because that adds the MDR on top of GDPR.

Kirsten Bondo Vraa has more than ten years of experience in pharmaceutical quality assurance, and we bring the same approach to data protection: requirements are written down, traced to tests and documented as we go rather than at the end. You get the code, the documentation and ownership. See how we build health and life science software.

Next step

If you are building a health app or a system that handles patient data, we can walk through the data flow with you and point out where GDPR shapes the architecture. It is a no-obligation conversation. Get in touch, or read on about ISO 13485 certification for medical device software.

ISO 13485 certification for medical software: time and cost

info@bon.do (Morten Bondo Vraa) — Fri, 25 Jul 2025 00:00:00 GMT

ISO 13485 certification means an accredited certification body has audited your quality management system (QMS) and found that it meets ISO 13485:2016. For medical device software, that system covers design controls, risk management to ISO 14971, a software lifecycle to IEC 62304 and traceability from requirement to test. A small software company should typically allow 6–12 months to obtain certification.

We build software for medical devices and work under our clients’ quality systems. This guide draws on our experience in those projects: where the time goes and what surprises teams coming from conventional software development.

What is ISO 13485?

ISO 13485 is the international standard for quality management systems for medical devices. The current edition is ISO 13485:2016. According to TÜV NORD, ISO reconfirmed it without changes at its latest systematic review, so it stays unchanged until April 2030. In the EU, EN ISO 13485:2016+A11:2021 is harmonised under the MDR by Commission Implementing Decision (EU) 2022/6, so a system that follows the standard is presumed to meet the corresponding requirements of the regulation.

The standard matters outside the EU too. The FDA’s Quality Management System Regulation (QMSR), in force since 2 February 2026, incorporates ISO 13485:2016 by reference into 21 CFR Part 820. A system built to ISO 13485 is therefore also the best starting point for the US market, even though the FDA does not require an ISO certificate and retains some additional requirements of its own.

Is ISO 13485 certification a legal requirement for medical software?

No, not the certificate itself. Article 10(9) of the Medical Device Regulation (EU) 2017/745 requires every manufacturer to have a quality management system, whatever the class. ISO 13485 is the harmonised standard for that system, and from Class IIa a notified body assesses the system as part of the conformity assessment. In practice it expects ISO 13485.

Whether a quality management system is required depends on whether the software is a medical device. It usually is if it is intended to diagnose, prevent, monitor, predict or treat disease, such as image analysis, clinical decision support or an app that monitors patients’ vital signs. Under classification Rule 11 of the MDR, most medical software ends up in Class IIa or higher.

Class	Risk	Quality management system	Notified body
I	Low	Required, certificate optional	No, except sterile, measuring and reusable surgical devices
IIa	Medium	Required, ISO 13485 expected	Yes
IIb	Medium to high	Required, ISO 13485 expected	Yes
III	High	Required, ISO 13485 expected	Yes, with the most extensive assessment

In Denmark, the Danish Medicines Agency (Lægemiddelstyrelsen) is the competent authority for medical devices. Devices still sold under an old directive certificate have a transition period until 31 December 2027 or 31 December 2028 depending on class, provided the manufacturer has an MDR quality system and an agreement with a notified body (Regulation (EU) 2023/607). In December 2025 the Commission proposed a targeted revision of the MDR and IVDR. Watch whether it changes the deadlines for your product.

What does ISO 13485 require for software development?

ISO 13485 requires development to follow a controlled, documented process in which every requirement can be traced to design, code, tests and risk assessment. For software that comes down to four things:

The quality system: quality policy, responsibilities, document control, change control, supplier control, training, and management of nonconformities and corrective and preventive action (CAPA)
Design controls (clause 7.3): planning, design inputs and outputs, reviews, verification, validation and transfer, with a design history that shows how the product came to be
Risk management: ISO 13485 requires a documented risk management process throughout product realisation. ISO 14971:2019 is the recognised standard for that process and the one notified bodies expect to see
Software lifecycle: IEC 62304 covers planning, requirements, architecture, implementation, verification, release and maintenance, scaled to the software safety class A, B or C

Validation means showing that the software meets user needs under realistic conditions: a validation plan, acceptance criteria, a production-like environment and a report with a traceability matrix. Agile development fits well, as long as requirements, risks and test evidence are updated in every sprint rather than documented only at the end.

How does ISO 13485 certification work, step by step?

With most certification bodies, the process runs from gap analysis and QMS implementation through audits to certification and ongoing surveillance:

Step	What happens	Typical duration
1. Gap analysis	Compare current practice with the standard and prioritise the gaps	2–4 weeks
2. Build the QMS	Procedures, templates, design controls, risk management and training	3–6 months
3. Run it and collect evidence	Use the system on real work so records exist	2–4 months
4. Internal audit and management review	Find nonconformities yourself and close them	1–2 months
5. Stage 1 audit	The certification body reviews documentation and readiness	1–2 days
6. Stage 2 audit	Auditors see the system in use through interviews and sampling	2–5 days
7. Certificate and surveillance	The certificate lasts 3 years, with a surveillance audit every year and recertification in year 3	Ongoing

Choose a certification body accredited for ISO 13485, ideally one that is also a notified body under the MDR so the audits can be coordinated. Examples include BSI, TÜV SÜD, DNV, DEKRA and SGS. Book early, because the wait for an audit can be several months. An MDR certificate from a notified body is a separate thing: it is valid for at most 5 years and requires surveillance at least once a year.

How long does ISO 13485 certification take?

Typically 6–12 months from gap analysis to certificate for a small company. The seven certification steps, from gap analysis to the stage 2 audit, can partly overlap, but waiting for audit days and closing nonconformities often adds one to three months.

4–6 months: the processes are already in use, and the main gap is documentation
6–12 months: the typical path, with a moderate documentation gap
12–18 months: from scratch, with no existing quality system

Certification is only one part of the timeline to market. Our roadmap from idea to CE marking shows how the quality system fits with classification, development and the notified body review.

How much does ISO 13485 certification cost?

Certification has become much cheaper than many expect. For a small software company with its own team and templates, the largest external cost is the certification body’s audit, around DKK 55,000–115,000. Consultancy is what moves the budget most. The figures in the cost table are converted from OpenRegulatory’s cost model (August 2026), which is anchored to published fee schedules. They are planning figures, not quotes.

Item	Indicative level
Certification body, initial certification	around DKK 55,000–115,000
Templates and eQMS tooling	from DKK 0 (free templates exist)
Consultant, targeted review	around DKK 60,000–150,000
Consultant, full implementation	around DKK 185,000–450,000
Total external cost	around DKK 55,000–565,000
Internal resources (our estimate)	200–500 hours
Annual surveillance audits (typically 1–3 audit days)	around DKK 15,000–55,000

The largest cost is rarely the certificate. It is the internal time it takes to write the procedures and then live by them.

How does a software partner work under your QMS?

The manufacturer owns the quality system, and an external software partner is a supplier you control under ISO 13485 clause 7.4 on purchasing. The partner works to your procedures, or to its own procedures that you have assessed and approved, and provides the records needed for your design history.

Ask a prospective partner:

How do requirements trace to design, code, tests and risks?
Which parts of IEC 62304 do you cover, and how do you determine the software safety class?
What documentation comes with each release?
How are changes handled after validation?
How is SOUP, meaning third-party libraries, documented along with its vulnerabilities?
Can you support post-market surveillance once the product is live?

At bon.do, Kirsten Bondo Vraa has more than ten years in pharmaceutical quality assurance, and Morten Bondo Vraa has built software for more than 22 years. We built the backend for a CE-marked medical device, where every recording is tied to the device, the subject and the operator, and the result must be traceable back to the raw signal. We write the documentation for your QMS as we go, and you own the code and all IP. Read more about our software development for medical devices and life science.

Next step

If you are facing a gap analysis or a software project under ISO 13485, we are happy to have a no-obligation conversation about how development fits into your quality system. Get in touch, or read about GDPR and health data and validating AI in life science.

Choosing software architecture: monolith or microservices?

info@bon.do (Morten Bondo Vraa) — Fri, 20 Jun 2025 00:00:00 GMT

To choose the right software architecture, start with the simplest structure that can work, usually a modular monolith, and move a part of the system into its own service only when a measured need demands it. That need is a different scaling pattern, a failure that must be isolated, teams that block each other, or a compliance boundary. Security, observability and traceability are designed in from day one, because they are expensive to bolt on later.

This guide is for founders, product owners and CTOs who have to make or approve that choice. It draws on our experience at bon.do when we build backends for medical devices, health apps and SaaS products, and when we take over systems that other vendors started.

What is software architecture, and why is it a business decision?

Software architecture is how a system is divided into parts, how those parts talk to each other and where the data lives. It decides how quickly you can change the product, what it costs to run, how it fails and how easy it is to pass an audit.

Architecture affects the business in four areas:

Speed of change. Can a new requirement be delivered in a sprint, or does it touch five modules?
Running cost. Hosting, monitoring and the people needed to operate it.
Risk. What happens when a component or a cloud region fails.
Compliance. Whether you can show an auditor who changed what, when and why.

That is why architecture should not be left to one developer’s favourite stack. It has to follow the product roadmap, the size of the team and the rules the product must meet. A system that handles clinical data has different needs from an internal reporting portal.

Monolith, modular monolith or microservices: which should you choose?

For most new products, a modular monolith is the right starting point: one application and one database, divided into modules with strict boundaries. Microservices pay off when several teams need to release independently or when parts of the system have clearly different load, failure or compliance needs.

	Monolith	Modular monolith	Microservices
Deployment	One unit	One unit	Many independent units
Internal boundaries	Often blurred	Strict modules, one owner each	Network boundaries
Operational load	Low	Low	High: networking, tracing, many pipelines
Data consistency	Simple transactions	Simple transactions	Distributed, often eventual consistency
Good fit	Prototypes, small tools	Most new products and small teams	Several teams, very different load or isolation needs
Main risk	Turns into a tangle	Boundaries erode without discipline	Cost and complexity before they are needed

Microservices are a good choice when:

several teams need to develop and deploy without waiting for each other;
one part of the system has a clearly different load pattern, such as sensor ingress or batch processing;
one part has different compliance or isolation requirements.

Microservices are a poor choice when:

the team is small and the operational burden outweighs the benefits;
the boundaries between domains are not yet understood;
monitoring, automated deployment and failure handling are not in place.

A modular monolith with well-defined boundaries keeps the door open. If a module later has to become a service, it is a move, not a rebuild. Serverless functions fit the same logic: they are useful for spiky, event-driven work, but cold starts, platform limits and vendor lock-in make them a poor default for the core of a regulated product.

How do you choose the right architecture? A seven-step method

Choose the architecture from the product, the domain and the non-functional requirements, not from a preferred technology, and record each decision so it can be revisited:

Understand the product. Who uses it, what data does it process, and which rules apply (GDPR, MDR, IEC 62304, customer security requirements)?
Map the domain. Divide it into bounded contexts before you pick technology.
Write down the non-functional requirements. Response times, availability target, data volumes, retention and recovery time. These drive the architecture more than the features do.
Choose the simplest thing that can work. A modular monolith and a relational database go a long way.
Decide what must scale or fail separately. Only the parts that actually have a different need.
Build in security, observability and traceability from the start. It is cheaper than retrofitting.
Record the decisions. Write short architecture decision records (ADRs) covering the context, choice and consequences, and revisit them as the product grows.

How does architecture affect cost?

Architecture drives three costs: the cost to build, the cost to run and the cost to change. The third is usually the largest, because a system where every new requirement touches many modules gets more expensive with every release, whatever it cost to build.

Build cost grows with every extra service, database and integration that has to be developed, tested and deployed. Microservices are not free: they need networking, monitoring, pipelines and people who can operate them.

Running cost depends on how the system uses cloud resources. The levers that matter most:

Right-size from monitoring data, not guesswork, and turn off non-production environments outside working hours.
Commit stable workloads to reserved capacity or savings plans, and keep on-demand pricing for unpredictable load.
Use managed services for databases, queues and storage where the savings in operational effort outweigh the higher unit price.
Watch data transfer, which is often billed when traffic leaves the cloud or crosses regions.
Set budget alerts, because pay-per-use services and autoscaling can turn a traffic spike into a large bill.

We have seen the effect first-hand. When we rebuilt the MindPlus app and backend, the monthly hosting and service cost fell by 98%. The old product had been through several vendors and an expensive hosting setup; the new backend was designed to run without a large operations budget.

How do you scale without overbuilding?

Scale when measurements show you need to, not before. Keep the application stateless so it can run as several instances behind a load balancer, and scale a part of the system independently only when its load pattern differs from that of the rest.

Vertical scaling means a bigger machine. It is simple, but it has a ceiling, often needs a restart and gets expensive at the top end.
Horizontal scaling means more instances. It needs stateless application code, with sessions and state in a database, cache or queue.

On Kubernetes, the Horizontal Pod Autoscaler adds or removes instances based on CPU, memory or custom metrics such as queue length. According to the Kubernetes documentation, the Vertical Pod Autoscaler recommends or applies new CPU and memory requests, either by recreating pods or, on clusters that support it, by resizing them in place. Recreating a pod involves a restart, so do this with care for databases and other stateful workloads, where a restart means a failover.

A monthly capacity review is worth more than an architecture built for a load that never arrives.

Which security decisions belong in the architecture?

Security by design means the architecture itself limits what an attacker can reach and what a mistake can break. The core principles are least privilege, defence in depth, secure defaults, a small attack surface and failing safely.

In practice:

Least privilege. Every user, service and integration gets only the access it needs, enforced by role-based access control.
Defence in depth. Network, application, data and identity are protected separately, so protection does not depend on a single control.
Encryption in transit and at rest. TLS everywhere, and encrypted storage for sensitive data.
Secrets out of the code. A secret manager such as Azure Key Vault, not .env files in Git.
A secure supply chain. Pinned and scanned dependencies and a build pipeline you can trust.

The OWASP Top 10:2025 confirms that many of the biggest web risks start in design: broken access control is still first, security misconfiguration is second, software supply chain failures are new at third, and insecure design and logging and alerting failures are on the list too. If you work towards ISO/IEC 27001, Annex A control 8.27 asks you to define and apply secure engineering principles to your architecture, and control 8.25 to build security into the development life cycle. Zero trust is one way to meet that, not a named requirement.

How do you design for reliability and observability?

Assume that every component will fail and design for it. Remove single points of failure where the business case justifies it, and make sure you can see what the system is doing before your users tell you.

Make sure you have:

Metrics: response time, error rate, queue length and the business numbers that matter.
Structured logs with a correlation ID, so one request can be followed across components.
Distributed tracing once there is more than one service.
Alerts only for things someone must act on. Too many alerts and nobody reacts.
Tested backup and restore. A backup that has never been restored is not a backup.

Set the availability target deliberately. 99.9% allows about 8.8 hours of downtime a year; 99.99% allows about 53 minutes. Each extra nine needs more redundancy and automation, so weigh its cost against what downtime actually costs you. For a medical product, also plan what the user sees when a service does not respond: can a clinician carry on, and who is notified?

What changes when the software is regulated?

In life science, medtech and healthcare, the architecture is part of the evidence. Auditors and notified bodies expect to see a documented structure, traced requirements, controlled changes and an audit trail, so these belong in the design from the start.

IEC 62304. For software safety classes B and C, clause 5.3 of IEC 62304:2006+A1:2015 requires a documented architecture that identifies the software items and their interfaces, and verification of that architecture. For class C, segregation needed for risk control must be identified. A second edition of the standard is in preparation; build to the one in force.
Traceability. Every requirement should trace to a design element, a test and a release. Our ISO 13485 guide covers the quality system around it.
Audit trail. According to 21 CFR 11.10(e), FDA Part 11 requires secure, computer-generated, time-stamped audit trails for electronic records, and GxP customers will ask for the same. Who changed what, when and why has to be in the data model, not in a spreadsheet.
Logging and GDPR. Logs often contain personal data. Log what you need, pseudonymise identifiers, set retention periods in line with the storage limitation principle in GDPR Article 5(1)(e), and protect access. ISO/IEC 27001 controls 8.15 (logging) and 8.16 (monitoring) describe the expectations.

A clear domain model with documented interfaces is easier to validate than a system where everything depends on everything. Two of our projects show how requirements, rather than trends, determine the architecture. The backend we built for a CE-marked medical device is one .NET API with SQL Server on Azure, with device management, recordings and quality control as part of the same backend. The Wear & Care platform receives continuous sensor data and sends alarms by push, SMS and SignalR, so it uses message queues and runs in Kubernetes.

When should you refactor or split the system?

Refactor when a change that should be small touches many parts of the system. Split a module into a service when it needs to scale, deploy or fail independently, or when several teams block each other in the same codebase. Do it before the next feature, not after.

Warning signs we look for when we take over a system:

Simple changes need coordinated releases of several parts.
Nobody can say which module owns a piece of data.
Incidents are found by customers, not by monitoring.
Audit questions take weeks to answer because evidence lives outside the system.

What is the next step?

Choose the simplest architecture that lets you deliver the next requirement without breaking existing functionality and that you can explain to a developer, a CTO and an auditor. Start simple, measure, and move the boundaries when there is a reason.

If you are about to start a product or are stuck with one that has become hard to change, book a call. We will look at your requirements and give you a free project assessment with a recommended architecture for the system.

AI medical device validation: data, bias and the EU AI Act

info@bon.do (Kirsten Bondo Vraa) — Thu, 15 May 2025 00:00:00 GMT

AI in medical devices is allowed and in use, but a model that works in a notebook is not a product you can use on patients. When AI software has a medical purpose, it must meet the MDR or IVDR, be developed under IEC 62304, be risk-managed under ISO 14971 and be validated for its intended purpose. If the device needs a notified body, the EU AI Act’s high-risk requirements also apply from 2 August 2028.

This article covers the work between the promising model and the CE-marked version: classification, rules, validation, data, bias and updates.

When is AI software a medical device?

AI software is a medical device when the manufacturer intends it to diagnose, prevent, monitor, predict or treat disease in individual patients. The intended purpose, not the technology, determines whether the software is a medical device. An AI model that plans staff rotas is not a medical device. An AI model that flags suspicious findings on an X-ray is.

The class follows from Rule 11 in Annex VIII of the Medical Device Regulation (EU) 2017/745. Software that provides information for diagnostic or therapeutic decisions is Class IIa by default, and Class IIb or III if a wrong decision can cause serious deterioration or death. Software that monitors physiological processes is Class IIa. All other software is Class I. In vitro diagnostic software is classified under the IVDR’s own rules.

The European guidance MDCG 2019-11 rev.1, revised in June 2025, works through the rules with examples, including AI. National authorities such as the Danish Medicines Agency publish their own guidance for manufacturers of software and apps. Our roadmap from idea to CE marking shows how the class shapes time and budget.

Which rules apply to AI in medical devices?

AI in a medical device must comply with the same rules as other medical software, plus the EU AI Act when the device is high-risk. Most of the work overlaps: a good requirements process, risk assessment and test strategy can support compliance with all of the frameworks if they are properly documented from the start.

Framework	What it covers
MDR / IVDR	Whether the product is a medical device, its class, clinical evidence and post-market surveillance
IEC 62304	The software life cycle: requirements, architecture, verification, maintenance and SOUP
ISO 13485	The quality management system, including design controls and change control
ISO 14971	Risk management, including risks from model errors and bias
EU AI Act	Data governance, documentation, transparency, human oversight and robustness for high-risk AI
GMLP	Ten principles of good machine learning practice, published by the IMDRF in N88 (January 2025)

When does the EU AI Act apply to medical devices?

The EU AI Act (Regulation (EU) 2024/1689) makes AI in a medical device high-risk when two conditions are met: the AI system is the device itself or a safety component of it, and the device needs a notified body assessment under the MDR or IVDR. Software in Class IIa and above is therefore usually in scope. Self-declared Class I software is not.

The implementation timetable has changed:

2 February 2025: Prohibited AI practices and the AI literacy rules apply. Since the 2026 amendment, providers and deployers must take measures that support AI literacy among their staff.
2 August 2026: The transparency rules in Article 50 apply, including the requirement that people must know they are interacting with AI.
2 August 2028: The high-risk requirements apply to AI in products such as medical devices. The date was originally 2 August 2027, but was postponed by the Digital Omnibus Regulation (EU) 2026/1744, published on 24 July 2026 and in force from 27 July 2026.

The joint MDCG and AI Board guidance MDCG 2025-6 from June 2025 explains how the rules fit together. In short, the AI Act does not change the MDR class, the notified body assesses both sets of rules in one procedure, and the AI requirements can be built into the existing quality system and technical documentation.

How do you validate an AI model in medical software?

To validate an AI model, gather evidence that the product does what you claim for its intended users and patients. AI adds a layer: the model’s behaviour depends on data, and data changes.

A practical order:

Define the intended purpose. Who uses the product, for which decision, and for which patient population? That is what you validate.
Lock the data and the model. Version the training data, code, hyperparameters and the final model, so the result can be reproduced.
Test on independent data. Test data must not overlap with training data and should reflect clinical reality, ideally collected at sites other than those used to collect the training data.
Document performance and errors. Report results overall and for relevant subgroups, using clinical measures such as sensitivity and specificity rather than a single accuracy score.
Test the workflow. Usability under IEC 62366-1: does the clinician understand the output, and what happens when the model is uncertain?
Monitor after release. Data drift and falling performance must be caught before they become a clinical problem, as part of post-market surveillance.

What does the data need to look like?

Training and test data must be of sufficient quality, representative of the intended patient population and documented. If the data cannot be documented, the model cannot be validated.

Quality. Missing values, different units and signal noise must be handled explicitly and described.
Representativeness. The data must cover the population the product will be used on, not only the patients who were easy to recruit.
Traceability. Every training and test set must be traceable to a version, a source and a processing step.
Data protection. Health data is a special category of personal data under GDPR Article 9. You need a legal basis, pseudonymisation and access control, and a data processing agreement with the vendors who process the data.

How do you handle bias in medical AI?

Handle bias in medical AI through risk management: it is a safety issue, not only an ethical one. If the model performs worse for a patient group, that is a difference in safety and performance that must be handled in risk management.

Treat bias as part of the design:

Map which groups are under-represented in the data, for example by age, sex, ethnicity or device type.
Test performance separately for the relevant groups, with acceptance criteria set in advance.
Document the decisions made to address bias and the limitations included in the instructions for use.
Monitor whether the distribution changes after release.

No technical fix removes all bias. You can make it visible, manage it and document it.

What happens when the model needs an update?

A retrained AI model is a change to the device. Under the MDR you must assess whether the change is significant, and a significant change to Class IIa software or higher must be approved by the notified body before release.

The AI Act allows for planned change: changes that are described in advance and included in the technical documentation at the initial conformity assessment are not a substantial modification. In the US, the FDA has had final guidance on Predetermined Change Control Plans (PCCP) for AI-enabled devices since December 2024. According to the FDA’s current PCCP guidance (August 2025), a PCCP describes the planned modifications, how they will be developed and validated, and their impact, and the FDA reviews it as part of the marketing submission.

In practice, most AI products are released with a locked model. If the model is meant to keep learning, the change protocol, the tests and the limits on what may change must be in place from the start.

What we see in practice at bon.do

In our work building software around AI in regulated settings, traceability and human oversight are recurring concerns. We built the backend for a CE-marked medical device in which a seismographic AI algorithm estimates VO₂max from the vibrations of the heart. The requirement was to make every result traceable to the raw recording, the device, the operator and the subject. That traceability is what makes the algorithm’s output usable in an audit.

On QualiBooking, a clinic platform that is not a medical device, AI notes run through a provider layer, and the practitioner reviews and signs every note. Same principle: the model can be swapped, and a human stays in control.

Whether you build in-house or with a partner, you should be able to answer:

Who owns the data, the model and the code?
Can the model be replaced without rebuilding the rest of the product?
How are model changes documented and approved?
Who monitors the model in use, and what triggers action?

These questions will arise during due diligence or an audit.

Next step

Start with a narrow clinical problem and confirm the class before you build. Build the smallest version that can be tested, document the data, the model and the decisions, and choose an architecture where the model can be swapped without rebuilding the whole product. Read more about ISO 13485 and the quality system and GDPR and health data.

If you want a second pair of eyes on your AI product, book a free project assessment. We go through the architecture, data and documentation with you, with no obligation. You can also read how we build regulated health and life science software.

Who owns the source code? A software ownership guide

info@bon.do (Morten Bondo Vraa) — Fri, 04 Apr 2025 00:00:00 GMT

Picture this: your software is live and works. A year later you want to change supplier, build on it with your own team, or integrate it with a new platform. Then you find out that you do not own the source code, that the data is stuck with the old vendor, or that the domain is registered in the vendor’s name. That is vendor lock-in. It is expensive, and a few requirements at the start prevent it.

This guide covers the digital assets you should own as a software buyer, and what to ask your development partner for before you sign.

Who owns the source code?

The developer does, unless the contract says otherwise. Under the Danish Copyright Act, copyright initially belongs to the person who creates the work, and § 59 gives an employer the copyright to computer programs its employees write as part of their job (ophavsretsloven). When you buy software from an agency, the agency holds the rights to its employees’ code. Paying the invoice does not transfer those rights to you.

The transfer has to be agreed, and it should be explicit. § 53(3) of the Act means that a transfer of the right to use a work in one way does not cover other ways. A contract that only lets you “use” the software may not let you change it, have another supplier change it, or sell it on.

So ask for:

a written assignment of the rights to the custom code and documentation, not only a licence to use them
an explicit right to modify, further develop, distribute and sub-license
a list of the vendor’s pre-existing components, frameworks or libraries, and the licence you receive to use them
a list of open source components and their licences, so you know your obligations

The law differs between countries. If your supplier or your company is outside Denmark, check which law governs the contract. This guide is practical advice, not legal advice; have a lawyer read the actual contract.

What about code written with AI?

Copyright protection for AI-assisted code depends on the human creative input. Copyright protects original expression that reflects a person’s own creative choices. The Confederation of Danish Industry points out that code produced by AI with little human input may not meet that threshold, while code for which a developer makes the key design choices and edits the result may do so (DI).

In practice: ask your supplier how they use AI, and make sure the contract and the delivered documentation (architecture notes, version history, reviews) show the human work behind the product.

Why is clear ownership critical?

Clear ownership lets you change supplier, hire in-house, raise capital or sell the company without the technology holding you back. It is not just a legal formality that matters when you exit.

When ownership is unclear, four problems tend to show up:

Switching gets expensive. A new supplier has to recreate what you have already paid for.
Data gets hard to move. The export comes in a format nobody else can read.
Operations depend on one person. Nobody else has access to the accounts, the code or the infrastructure.
Due diligence fails. An investor or buyer discovers that the company does not own its own software.

In regulated fields such as medtech and the life sciences, you also need access to the code, the data and the documentation to respond to audits and keep the product’s technical file up to date, both on the way to CE marking and after launch.

The assets you should own

Secure ownership of seven assets: source code, data, domain and DNS, hosting, third-party services, documentation and a written exit plan, with the access, documentation and rights you need for each. This does not mean doing everything yourself.

1. Source code and version control

Keep the code in a Git repository under your own organisation on GitHub, GitLab, Azure DevOps or similar, not under the vendor’s account. A user account in someone else’s organisation is not ownership.

All repositories, including infrastructure as code and deployment scripts.
At least two administrators on your side.
A codebase that builds without access to the vendor’s private environment.
The secrets and configuration needed to run it, stored where you control them.

2. Database and data

Data is often the most valuable asset and the hardest to move. You should be able to export it in an open format without asking permission.

A documented data model and export process.
Database access through an account you own.
Backup and restore procedures that have been tested, not just configured.

If the vendor processes personal data for you, GDPR requires a data processing agreement that makes the vendor delete or return all personal data at the end of the service, as you choose (GDPR Article 28(3)(g)). Use that clause.

3. Domain and DNS

Register the domain in your company’s name, with your own contact details, and retain the login credentials for the registrar account. The domain is your address on the internet. The same applies to the DNS zone, because DNS controls email, subdomains and verification records. The vendor can get access to set up records; you retain ownership.

4. Hosting and cloud

The cloud account is often where lock-in is most expensive. If the vendor owns the account, the vendor effectively owns your operations.

The cloud account is yours, with your billing and your security policies.
The vendor gets role-based access, not ownership.
The infrastructure is described as code, so it can be recreated.

Since September 2025 the EU Data Act has also given business customers rights when switching between cloud and other data processing services, and switching charges are being phased out by 12 January 2027 (Data Act). Amendments are under negotiation, so check the current text. These rights help, but they do not replace owning the account.

5. Third-party services and API keys

Modern products run on many services: payment, email, SMS, AI, maps, analytics and support. Each one has an account and a key. If the key sits in the vendor’s account, it is not yours. Keep a list of each service, its purpose, who owns the account, where the keys live and what happens to the subscription when the collaboration ends.

6. Documentation

Documentation enables another team to take over the system. Ask for the architecture and data model, including the architecture decisions and their reasons, a runbook for operations, deployment and rollback, the test strategy and known limitations, and a handover that includes a walkthrough, not just a zip file.

7. A written exit plan

Describe in the contract how code, data, accounts and documentation are handed over when the collaboration ends, whatever the reason, and what the vendor helps with during the transition. Source code escrow is mainly relevant when the vendor keeps the code, for example with licensed or SaaS software. If the code is already in your repository, the exit plan matters more than escrow.

Software ownership checklist

Go through this list before you sign, and again once a year:

The contract assigns the rights to the custom code and documentation to you.
Third-party and open source components are listed with their licences.
Every asset has a named owner in your company.
All accounts (Git, cloud, domain, DNS, third-party services) are in your company’s name.
Data can be exported in an open format.
A data processing agreement covers deletion or return of personal data.
There is a documented exit plan.
Someone outside the vendor has built and run the system from your repository.

How bon.do handles ownership

At bon.do, all code, data and IP are yours from day one. We work in repositories and cloud accounts in your name where possible, build on open, well-documented tools, and include documentation and a handover in the work, whether it is a fixed-scope MVP or an ongoing team. Ownership is part of how we build and run software for our clients.

Unsure who owns what in your current product? Contact us for a no-obligation review of your code, accounts and contract.

Bon.do · Insights

How much does an app cost in Denmark? Prices for 2026

How much does an app cost in Denmark?

What makes an app more or less expensive?

Native or cross-platform: which is cheaper?

What does an app cost to run and maintain?

What does a regulated or medical app cost?

Hourly rate or fixed price?

How to keep the price down without cutting corners

How bon.do estimates your app

From idea to market: medical device software development roadmap

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

Is your software a medical device?

Stage 1: validate the problem before you write code

Stage 2: prototype and requirements

Stage 3: an MVP with the quality system in place

Stage 4: technical documentation and CE marking

What does medical device software development cost?

How do you fund medical software in Denmark?

Launch and operation after the CE mark

How to choose a development partner

What bon.do does

Next step

GDPR and health data: processing patient data lawfully in Denmark

What counts as health data under GDPR?

Which legal basis should you use for health data?

When does health data require a DPIA?

What does valid consent for health data look like?

Which security requirements apply to patient data?

How long should patient data be kept?

Can health data be stored with a US cloud provider?

What must a data processing agreement contain?

What happens when health data is breached?

Which Danish rules apply on top of GDPR?

How we work with GDPR in health software

Next step

ISO 13485 certification for medical software: time and cost

What is ISO 13485?

Is ISO 13485 certification a legal requirement for medical software?

What does ISO 13485 require for software development?

How does ISO 13485 certification work, step by step?

How long does ISO 13485 certification take?

How much does ISO 13485 certification cost?

How does a software partner work under your QMS?

Next step

Choosing software architecture: monolith or microservices?

What is software architecture, and why is it a business decision?

Monolith, modular monolith or microservices: which should you choose?

How do you choose the right architecture? A seven-step method

How does architecture affect cost?

How do you scale without overbuilding?

Which security decisions belong in the architecture?

How do you design for reliability and observability?

What changes when the software is regulated?

When should you refactor or split the system?

What is the next step?

AI medical device validation: data, bias and the EU AI Act

When is AI software a medical device?

Which rules apply to AI in medical devices?

When does the EU AI Act apply to medical devices?

How do you validate an AI model in medical software?

What does the data need to look like?

How do you handle bias in medical AI?

What happens when the model needs an update?

What we see in practice at bon.do

Next step

Who owns the source code? A software ownership guide

Who owns the source code?

What about code written with AI?

Why is clear ownership critical?

The assets you should own

1. Source code and version control

2. Database and data

3. Domain and DNS

4. Hosting and cloud

5. Third-party services and API keys

6. Documentation

7. A written exit plan

Software ownership checklist

How bon.do handles ownership