For more than eight years our engineers have worked inside one of the large German medical imaging and radiotherapy manufacturers. The client has kept widening our responsibilities and the expertise it asks from us, and today more than twenty of our engineers and specialists work there, across several projects in development, test automation and DevOps. In that time the manufacturer has consistently passed its internal and FDA audits, and its products built on the platform received several 510(k) clearances, and we are proud of our share in that work.
Adding an outside team to a regulated organisation can cost more than it brings: senior time spent on onboarding, extra work for the quality department, gaps in the audit trail, and knowledge that leaves when people rotate. The way we work is built to avoid each of these.
More capacity without more risk
A large manufacturer rarely lacks engineers in general. What takes months to find is someone who is productive in a regulated codebase quickly and does not create extra work for the quality department. Every new person, internal or external, costs time from your senior engineers while they learn the code and the procedures.
Our engineers come with that background. They have written code under design control, they know what a traceability link is for, and they work inside an IEC 62304 lifecycle every day. They are productive in your codebase within weeks, and they fit into a team where the work affects patients' lives.
Your process, followed exactly
Our engineers use your tools, follow your procedures and sit in your reviews: your requirements system, your version control rules, your code review checklist, your definition of done.
In a regulated platform a bug fix needs a problem report, an impact assessment, a link to the affected requirements, a review by someone who knows the module, and a test that proves it. An outside engineer who skips one of those steps leaves a gap in a process you have to defend. We train our people on your procedures before they start, and we keep the same people on your account for years.
Records that hold up in an audit
When an auditor samples a change, the trail has to be complete whoever made it: the requirement, the design decision, the code review, the test, the release. Our engineers' work is in that trail like everyone else's.
That means training records for your procedures, documented before anyone touches production code. It means code reviews recorded in your tool, not agreed in a chat, and test results kept where your procedure says.
The same people, year after year
A platform with millions of lines of code is learned slowly. The first months of a new engineer are spent finding things, and if a supplier rotates people every year, you pay for that learning again and again.
Our engagement grew from a few people to more than twenty mostly because the same engineers stayed. They know where the old modules are fragile, which tests are slow for good reasons, and who in your team owns which decision.
People your team wants to work with
Technical skill is only part of what decides whether an engineer stays on your team for years. MedTech filters candidates on its own: many of the engineers who apply to us have a personal or family connection to medicine, someone close who was diagnosed or treated with technology like the one they would work on.
Beyond that, we look for people who cooperate, who can take criticism of their code and give it without making it personal, and whom your team is glad to work with. And people who understand what is at stake: decisions in this code end up affecting patients' health and their families' lives.
Start small, widen when you are ready
You do not have to hand over the core of a certified product to see how we work. We start at the edges: test automation, a build pipeline, bug investigations, a well defined feature. You see whether the code review is clean, whether the change came with its documentation, and whether anyone had to chase it.
With our clients that path has led from QA and DevOps to feature development in C++, .NET, Python and JavaScript, on desktop, client server and cloud systems, and from there to new DICOM versions, security hardening and the hard bug investigations that come from customer complaints. Each step was the client's decision, made after watching the previous one.
Your code and your data stay yours
Our engineers work on your machines or in your virtual environments, through your access controls, under your rules for what may be copied where. We answer questions about our own security practice in writing. AI coding tools are not used on your code unless your own policy allows them.
How to start
If you need more engineering capacity in development, test automation or DevOps, the useful first conversation is about your process and one concrete piece of work. Tell us where your team is stretched, and we propose two or three engineers who already know regulated development, with a scope you can judge within a few months. You can write to me at tamas.fodor@silurus-software.com.