Meet Nathan: Building the Infrastructure Behind AI-Powered Clinical Trials
As part of our “Meet the Builders” series, we spoke with Nathan about what drew him to DevOps, the realities of supporting both AI and SaaS systems, and the challenges of building infrastructure in a regulated environment.
What originally drew you to DevOps engineering?
I’ve always enjoyed problem solving, particularly when it involves making different parts of a system work together.
What drew me to DevOps was the challenge of building something that is cost-effective, efficient and scalable, while still being reliable and secure. Automation is also a big part of it. I’ve always been someone who will spend two hours automating a two-minute task if I know I’ll have to do it more than once.
What separates a good DevOps engineer from a great one?
Collaboration is so important. Working well within the DevOps team is one thing, but understanding the needs and challenges of the wider engineering function makes a huge difference. The goal is to make the development process as frictionless as possible so that projects can move smoothly into production.
You can have wonderful engineers who are experts in their field and come up with incredibly clever solutions, but if they can’t work effectively with others, things don’t progress efficiently. Miscommunication increases, and teams are more likely to make compromises just to avoid friction at deployment time. A great DevOps engineer understands the bigger picture — not just the system, but the people working within it.
What motivated you to join Qureight?
Qureight is the first place I’ve worked where it feels like the Company’s mission is genuinely focused on making a real impact on people’s lives. There’s also a wide range of technologies used across the business, and with our partners, which makes it an interesting environment to develop my skills further.
What are the hardest infrastructure problems you’re solving?
One of the biggest challenges is balancing competing priorities. You need systems to be secure, resilient, efficient and cost-effective, and improving one of those often has an impact on the others.
For example, increasing resilience typically means making systems highly available, which can require duplicating infrastructure. That improves reliability but also increases cost. A lot of the work is about finding the right balance between those factors.
What makes infrastructure for AI and medical imaging different from standard SaaS?
We effectively operate in two environments. On one side, we have a SaaS (Software as a Service) platform, which needs to meet the usual expectations around reliability, scalability and performance, as well as additional regulatory requirements because of the clinical context.
On the other side, we’re training AI models. That requires a very different setup, with more flexibility for experimentation and iteration. The challenge is that the outputs of that work then need to be integrated into the SaaS platform in a way that’s stable and compliant. Bridging those two worlds is where a lot of the complexity comes in.
What have you had to build or rework because off-the-shelf solutions weren’t enough?
Most of what we build is, by nature, a bespoke combination of existing tools and services. We do use off-the-shelf and open- source solutions where possible, but we often need to adapt them slightly to meet the range of requirements across both the SaaS and AI sides of the business.
At the same time, we try not to over-customise. Maintaining heavily modified tools can become a significant overhead, particularly when it comes to updates, security fixes and support. There’s a balance between building what you need and making use of what already exists.
How does your work impact clinicians or sponsors?
DevOps is a funny one. In some ways, the impact is quite broad, as we are responsible for the infrastructure that delivers products to customers and makes them accessible. But day to day, it’s not something users will directly see. If we’re doing our job well, everything just works and no one notices!
What excites you about the next few years?
The scale of growth across the business is really exciting. As Qureight works with more studies and customers, the impact of what we’re building increases. There’s real potential for the platform to make a meaningful difference in the medical world, and hopefully help a lot of people as a result.
What advice would you give someone thinking about joining the DevOps team?
Be ready to learn and collaborate. We’d rather try something, learn quickly and adjust than spend months building something that turns out not to be the right approach. The role also involves working across different parts of the business, which means being open to learning new technologies and ways of working. This can sometimes mean a more rapid planning, design, and implementation cycle than some people will be used to.
From a technical perspective, many different kinds of engineers can thrive at Qureight. What matters most is the ability to work together with others and adapt. We’re still a relatively small team, so people need to be comfortable working across different areas rather than specialising too narrowly. At the same time, it’s an environment where you can learn a lot, not just within DevOps, but across the wider platform.