5 Common Mistakes When Developing Software For Your Medical Device

At Firefinch, we love working with start-ups at the absolute forefront of innovation. They have great ideas, an exciting plan, and a lot of energy – they need to, right? The start-up world is exhausting!

When they come to us, they have usually built a fantastic team of scientists and people with medical expertise. They usually have people who have brought medical devices to market, too, which is excellent. However, what they often lack is experience in building the software for a medical device and the (strict) regulatory requirements on software for medical devices. If this sounds like you, then read on.

Over the years, we have seen some common mistakes recurring, which can be an unnecessary waste of time and money for these inspirational teams. So, we want to share some of the mistakes we see and solutions to help others avoid these pitfalls.

1. Staffing

If you are the CEO of a small start-up, you already have to wear many hats, so managing the whole software development task on top of your everyday responsibilities can be challenging and expensive, both financially and time-wise.

It’s tempting to hire the Post Doc/student you know that is a whizz at coding to develop your software, but do they have the right skillset to bring a device to market? Most of the medical device companies that Firefinch work with started life in a university, where there are a lot of people that are pretty good at coding, but being able to make the device work in an academic setting is quite different from making it into a mass-produced, compliant device that is fit for market reality. And as we explain, developing software without the end goal and regulatory compliance in sight can be very costly.

Once people realise this, the first question they usually ask is “Should I hire a software team or seek a partnership with software professionals?”, closely followed by “What skills do they need?”

Firstly, you are going to need a product owner – someone who will advise the team, know the regulations inside out, and ensure that requirements are being met for both software and hardware.

Tackling the internal or external resource question first, let’s consider salaries. What you will likely need for a typical device will be a Project Manager, a Developer and a Junior Developer for one year, which will cost you around £177k (Source: [2025 Tech and IT Salary Guide | Robert Half UK](https://www.roberthalf.com/gb/en/insights/salary-guide/technology) ). If you were to spend this money on an external contractor you would get a full team (at Firefinch you would generally have three developers on a project like this, fully skilled in building for your domain), who are able to hit the ground running and could deliver the same result around four times faster. You would of course still need some software support following the project, which is where you would use internal resource. It would be very expensive to rely on external contractors in the long term.

Hiring an external partner can also bring additional expertise more easily than you may want to hire for in the long term. That being said, developing software for your business also generates knowledge about your product so you need to ensure that this knowledge is transferred internally if you use an external partner. This can, of course, also be true for an internal team due to the risk of staff turnover.

This brings us to the second question: What skills do you need in your software team? Essentially, you need to cover five areas in addition to making sure the candidates are a good fit for your team.

Domain knowledge/experience. There are a lot of software developers out there, and many people who might understand the scientific technicalities of your product, but finding people who can work at that intersection is much harder. At Firefinch, our customers often tell us that they worked with other software developers but didn’t understand what the product was supposed to do. On top of that, the requirement to work within strict regulatory frameworks and your talent pool might start to look vanishingly small. Do not fear, developers know each other, and if you can get some help with recruitment from a developer who understands what you need, it shouldn’t be an insurmountable task.

Technical knowledge/experience. It can be really hard for a CEO/CSO to assess whether the people you are interviewing have the right technical expertise. They might talk about front ends and back ends and full stacks and clouds, but how can you tell if they really know what they are talking about or if they have just read a glossary of software terms? You will need a friendly expert to sit on your panel (consider a software consultancy) or a series of glowing references from previous roles.

Understand your business and goals. This one is a bit easier and accurate for everyone you hire. You want the developer to buy into what you are doing and understand how to build scale and reliability into your design.

Communication. This is not a given for every software developer, but it will be key to smoothing out issues as your product moves to market. Ensure you can speak the same language as your developers, whether internal or external.

Beware wizardry. Developers might want to use the coolest new thing, and investors might want to hear you are using the coolest new thing, but be careful not to be swayed by hype and ask yourself whether it is justified.

When considering an external partner, additional questions are: What is your exit strategy? How are you managing knowledge risk? Are you managing your intellectual property? Are you getting project-level support?

2. Stuck in the SOUP

SOUP or Software Of Unknown Provenance is a real issue that we see time and time again when working with companies that have started building their software without regulatory compliance in mind. And it’s really easy to do. Most coders and data analysts will start building algorithms on a standard operating system. But what is in the operating system, and have the components been risk assessed in a medical context? When developing for a medical device, IEC 62304 requires that SOUP components meet the standards expected of medical software. Essentially, you need to:

Identify SOUP components by name, version, and manufacturer
Analyse potential risks to patients, operators, or third parties
Document and validate requirements for function, performance, and safety
Manage updates of SOUP components

This becomes very difficult when you have pieced together various features from commonly available tools. At Firefinch, we have solved this issue by creating our own, clean operating system for medical devices. We can then add different components to see if they are necessary for the device’s functionality – if it’s not needed, then we don’t include it. This makes listing and assessing the SOUP much easier. There are other solutions. We suggest you ask your software developers how they plan to:

Insulate safety-critical parts of the system from the potential negative effects of SOUP
Conduct a thorough risk analysis and justify SOUP usage
Provide functional and performance requirements for each SOUP component
Develop a plan for SOUP management, maintenance, and product labelling.

The takeaway message on SOUP is to avoid it if you can, and for the components that you need, make sure you fully understand and document them.

3. Unclear decisions

When developing software for your medical device, you will talk a lot about requirements. By requirements, we mean capturing the overall behaviour of the software. These will be recorded in your Quality Management System (see point 4). Usually, requirements are organised into four categories:

Functional Requirements: Specifying what the software is expected to do

Non-Functional Requirements: Defines expected attributes such as security, scalability or usability

User Requirements: Relate to how the user interacts with the system, outlining their needs

Quality Requirements: Outlines expectations for quality of the end-product, such as reliability or performance

As you develop your software, you will need to make hundreds, if not thousands, of decisions and assumptions on these requirements and the solutions to meet those requirements. The problem is that to meet medical device regulations, you need to have proper traceability all the way from user needs through to design outputs. This is often missing when prototype software comes to us to be transformed into a compliant, market-ready software. User stories are a common way to record how decisions have been made. We take a user requirement such as “I want to change my password so that I can access the system securely” and map out what this means in terms of changes to the software to meet this requirement.

The same is true for other software requirements. Traditionally, requirements were defined using the Waterfall method before development could start, i.e. at the point of highest ignorance. Nowadays, more and more software teams are working in an agile, iterative manner that allows development to be completed in sprints, following AAMI TIR 45 guidance. In this way, tickets are produced that define a set of requirements, which are then designed, tested and launched with a well-maintained document trail. This allows bugs to be fixed early and users to test features before the whole release is ready, generating important feedback.

All of this helps provide clarity in the decision-making process, which is critical for medical device software. If the MHRA asks you, “What does this piece of code do?” then you should have a clear, documented response.

4. Not taking quality management seriously enough

If you are working in this space, you will want to familiarise yourself with these regulations and guidelines. The mistake that we often see, though, is developers not taking quality management seriously, which relates to ISO 13485. To be clear, it is essential to implement this standard for market entry to the UK, US, EU and most other markets around the world. The standard relates to how quality is managed in the design, production, installation and servicing of medical devices and related services. There are local variations of what this means in practice, so you will need to familiarise yourself with the best practice in the market you want to enter.

Companies developing medical devices will need to comply with this standard and, before entering the market, will want to have their devices certified that they comply with the standard. So what does this mean to the Med Tech innovator? It means any code not developed under a QMS will be classed as SOUP. It will also be impossible to pull previously developed code into the QMS, so the QMS must be in place before development begins. The person managing the quality mustn’t be the product owner, as a clear separation in the roles will allow an objective viewpoint on quality.

5. Not enough foresight for growth

Most companies don’t want to release their product onto the market and call it job done, right? The 5-year plan has growth on the horizon – and with growth comes a new set of headaches. Our final common mistake relates to companies that haven’t planned for growth. When you have 10,000 devices in use, then issues are bound to start to occur and you need a plan to mitigate these built into the software from the offset. For example:

What happens when users identify bugs in the software?
How do you add in cool new features to software that is in the field?
How do you upgrade software systems and components when new updates are released?
What do you do when the SOUP used by your device is no longer maintained by the provider?
If you expand into new markets, will there be new regulatory requirements and languages to build into the user interface?

Updates will need to be performed and validated to ensure that the instrument still conforms to the original specification. You will need to perform and certify Operational Qualification (that the device still works) and Performance Qualification (that it works how it’s meant to be working) tests after any update or part change (if these terms are new to you, read this Guide to Process Validation). So will have include a service plan that covers upgrades and bug fixes? What about new features – will you charge for these?

Nowadays, most devices have some kind of cloud connectivity, so updates to fix bugs and upgrade packages can be pushed to them. If you include cloud connectivity, you also need to include some kind of auditing system to show who has access to the cloud, exactly what they have access to, and a log of when they accessed it and what they did. You can imagine that a strong audit trail is particularly important in a medical device context where there is the risk of inadvertent access to patients’ health data.

Final thoughts

Developing a medical device is really exciting, and the potential for meaningful change to people’s lives is vast. As the CEO of a medical device company, your job is to be the inspirational leader who can speak to investors, buyers and product developers alike – it is not to develop software. Hopefully, this guide can help you navigate the challenges around developing the software for your device and avoid some of the common mistakes we see as a software consultancy working in this area every day.

The power of a quick chat is immense as you bounce ideas off an expert and get some free advice on your idea. To book a friendly, no obligation chat with Isabel, follow this link Meet Isabel

Firefinch have specialist expertise in developing software for medical devices, including medical imaging, cell analysis and DNA diagnostics. You can read our case studies here