What I Learned About Clinical Trials as a Software Guy

My team builds software for a client in clinical trials. Their platform helps companies decide where to run a trial: which countries, and which hospitals.

I knew how to build the software. I didn’t know the first thing about trials.

The first few calls felt like a different language. LPI. FQ. SQV. SIV. I nodded a lot, then Googled a lot more. (LPI means “last patient in”, the day the last person joins a trial. That one comes up a lot.)

Here’s what surprised me most.

A trial is a long relay race

I thought a trial was mostly about the drug. Turns out a huge chunk of the work is just getting it started.

Write the protocol. Work out which countries and sites can run it. Pick and check the sites. Sort out contracts and ethics approvals. Open the sites. Then recruit patients. Every step hands off to the next.

Our software sits in one of those steps, the “where should we run this” part. Seeing the whole chain showed me why a week saved early matters so much later.

Picking sites is educated guessing

Choosing a hospital isn’t a simple lookup. It’s a stack of guesses.

You start with how common the disease is. Then which sites ran similar trials, and how fast they recruited. Then the sites tell you how many patients they think they can bring.

The trick is comparing the layers. When a site promises far more patients than the numbers support, that’s a red flag. Sites tend to be a little too hopeful.

Clean data is the real product

A lot of trial data is public. ClinicalTrials.gov lists hundreds of thousands of trials for free.

The hard part is trusting it. The same trial shows up in more than one place. Dates are missing. One hospital is spelled five different ways.

That’s why companies pay for platforms like Citeline. A big part of what they pay for is clean data, where each trial is counted once and the details hold up.

Even then, people still check things by hand. Contact details especially. People change jobs, and no database keeps up.

Averages hide the real story

“This country recruits 2 patients per site per month” sounds useful. But it’s an average across every kind of trial. A cancer trial and a diabetes trial in the same country can behave nothing alike.

The better question is how fast trials like this one recruited there. Much harder to answer. Much more useful.

Rare disease flips everything

My favourite lesson. A feasibility expert I work with explained how rare disease trials really get planned.

With common diseases, you start from the data. With rare ones there’s barely any. Maybe one line saying “1 in 100,000 people”. Maybe three or four past studies.

So you start from the people. You read journal papers to find the leading researcher and hospital. You look for patient groups, because a patient group means a community, and maybe a list of patients. Those hospitals might never have run a trial, but they treat the patients.

As she put it, rare disease is about the people, not just the data.

What I’m taking with me

The best product rule I picked up came from her too: only collect what helps get patients enrolled. If a feature doesn’t help get the right patients into the trial faster, it probably doesn’t belong.

That works far beyond clinical trials.

The bigger lesson for me as a developer: you don’t need to know an industry before you build for it. Sit in the calls, ask the “dumb” questions, and let the experts draw you the map.

I’m still learning. But I don’t just nod in those calls anymore. Mostly.