Trying to break into the clinical trials space

Mike Guskov — Thu, 05 Nov 2026 07:21:51 +0000

Imagine someone has just been given a serious diagnosis. One of their options might be a clinical trial: a new drug or treatment regimen that isn't yet available in routine care. There's no shortage of places to look. The largest open registry, ClinicalTrials.gov, is free and lists more than 600,000 studies from all over the world.

So what's the problem? It's not that there's too little data. Quite the opposite: there's too much of it, and it's written for specialists. To figure out whether a trial is right for you, you have to read the inclusion and exclusion criteria and match them against your diagnosis, stage, previous treatment and a dozen other things. For someone without medical training, that means hours of comparing walls of text, and still a real chance of getting it wrong.

We decided to make exactly this part easier, and that's how Cintarra was born. This article covers how we got here, what we found on the market, how we built the product, what it cost, and whether it was worth the effort at all.

Where the project came from

A confession to start with: the idea isn't ours. More precisely, the niche was suggested to us by a doctor who works in clinical research.

We started with no budget and no experience in medical products. What we had was an idea, the drive to see it through, and free evenings and weekends. Oh, and ten years of designing interfaces of every level of complexity for every kind of audience.

Discovery

Target audiences and what they need

I can't say exactly when our first brainstorming call took place, and it doesn't really matter. What matters is that on that call we settled on the audiences to focus on, and agreed we needed to study them more closely to understand what to offer.

We ended up with four groups: patients (the main one), healthy volunteers, physician-investigators and sponsors. For each, we built a persona and a customer journey map (CJM). Then we walked each persona through four stages, from diagnosis to taking part in a trial, and mapped out actions, goals, emotions, pain points and touchpoints at every stage.

The most useful takeaway from the CJM: the emotional curve hits its lowest point in the first two stages (diagnosis and finding a trial), exactly where a person is left alone with the registry. Later, trial coordinators and site doctors get involved, and things get easier. So help is needed right at the start: finding trials and understanding whether you qualify before you ever call a trial site.

Competitors

When we started our competitor analysis (late 2025), the list looked like this:

ClinicalTrials.gov. The primary source and, essentially, our main competitor. Free, the most complete, updated daily. But it's a registry, not an assistant: there are filters, but the inclusion and exclusion criteria are a solid block of text for specialists, and matching them to your own situation is entirely on you.
Ancora.ai. Trial matching for cancer patients: you answer questions about your diagnosis and treatment and get a list of suitable trials. Free for patients, but focused primarily on oncology.
Trialing.org. Built for doctors, not patients: search by condition, biomarkers and trial ID, plus patient referrals to partner hospitals. Free for doctors; pharma companies and CROs pay. According to its website, it covers about 4,000 trials in 26 countries.

The bottom line: you get either a complete but raw registry, or convenient tools that are limited to one therapeutic area or built for doctors. Among the services we looked at, none helped a patient with any diagnosis check themselves against the criteria and understand the result. That's the gap we decided to aim for.

What we decided to build

Based on all of the above, we put together a core feature set. Although, to be honest, "hypotheses" is a better word for them:

Search by condition and location. Type your condition in plain language rather than an exact medical term, and immediately see the distance to the trial site.
Medical card. Describe your diagnosis, stage, previous treatment and biomarkers once and reuse it for every trial, instead of filling in the same thing on every questionnaire.
Match percentage. Show how well a trial fits, and keep two different situations apart: an explicit conflict with the criteria versus simply missing information about the patient.
Easy application. Help pick a suitable location and contact, and generate a message template.
New trial alerts. If nothing fits right now, people shouldn't have to check the registry every day themselves.

We couldn't validate these hypotheses before launch: paying $15 per interview sounds lovely, just not on our shoestring budget. So we went the other way around: launch an MVP first and test it on real users.

Architecture

The stack: React, TypeScript and Vite on the front end, Node.js with Express on the back end, MongoDB, hosted on Google Cloud Run. The stack itself is less interesting than how the product's design changed every time we hit a wall on speed or cost.

Our own copy of the registry

The first thing we did was stop hitting ClinicalTrials.gov on every search. We now keep our own copy of the registry in MongoDB, but not all of it: only trials that are recruiting now or will start soon.

We don't store everything, only what search and Match need: conditions, keywords, MeSH terms, eligibility criteria and trial locations. The full trial record is fetched from the registry only when someone opens it, and cached for a few hours. That keeps the database lean, and search runs on our own data without depending on an external API.

As a bonus, syncing taught us to spot changes: a trial has reopened recruitment, or a new site has been added. That came in handy later for alerts.

Match without a neural network

Our most important decision: the match percentage is calculated by deterministic rules, not by a model. The same data always produces the same result, and that result can be explained.
The medical card is compared with a trial across nine categories: diagnosis, age, sex, stage, location, current treatment, contraindications, biomarkers and exclusion criteria. A few principles we consider key:

An explicit conflict and missing data are different things. If age or sex clearly doesn't fit, or an exclusion criterion is triggered, Match is zero. But if the card simply lacks the information, the category stays "not verified": it earns no points, but it doesn't count as a match either.
No high score without a confirmed diagnosis. If the diagnosis isn't confirmed, Match is capped at 49%.
The percentage is not the probability of getting into the trial. It's a weighted estimate of how many criteria we were able to confirm. The final decision always rests with the trial site, and we say so explicitly.

Match is calculated for the top 100 candidates in the results, which are then re-sorted by it. Everything below stays in the default order. It's a trade-off between accuracy and database load.

Where we did need AI

We didn't get by entirely without a neural network; we just gave it the job it does better than rules: understanding people. In every case it's an inexpensive OpenAI model, called only where it's needed:

Search plan. A plain-language query ("KRAS-mutant lung cancer, Spain") is turned into a structured plan: the condition in English, a MeSH term, filters. One call per search, and the result is cached.
Filling in the card. You can describe your situation in text or upload a PDF of your medical records, and the model sorts it into the card's fields. Before processing, we ask for consent and strip direct identifiers from the PDF.
Diagnosis translation. If a diagnosis isn't written in English and isn't in our verified dictionary, the model translates it once, when the card is saved.

That said, a model's translation only helps find trials; it never confirms a diagnosis match. Only the verified dictionary can do that. For now it covers a handful of conditions, such as non-small cell lung cancer, triple-negative breast cancer and asthma, and it will keep growing.

The weekly trial digest skips AI altogether: the search plan is built locally from the card, and only trials with a Match of 50% or higher make the cut.

Reference data and APIs: where we saved money

Autocomplete was a story of its own. We didn't want to pay for every letter someone types into the "condition" field, so we went looking for free sources:

NLM Clinical Tables: a free API from the US National Library of Medicine. We use it for condition and gene suggestions.
Photon, built on OpenStreetMap data: city and country suggestions, also free.
Google Maps: we kept it only for geocoding and the map of trial sites on the trial page. We originally wanted to pull in clinic reviews and ratings too, but dropped the idea because of the price.

Design and front end

A quick reminder: I'm a designer, not a developer. So design and front end are the parts I handle with the most love and care. I'll also admit up front that I wanted to push the pixels myself, but naturally, Claude took over part of the work to speed things up.

Nothing groundbreaking, but still

In Figma, everything is built on variables: colors, typography, radii and spacing. On top of them sits a component library with variants: buttons, inputs, chips, badges and so on. In total, that's more than 30 components and around 530 variants.

There are mockups for every flow: home, search results, trial page, account and medical cards, settings, sign-in, favorites, info pages, 404/503 errors and emails. Each flow comes in three breakpoints (1440 px and up, 1024–1439 px and 320–1023 px), with every edge case we could think of.

The front end follows the same system: tokens were carried over to code one-to-one, and all components live in Storybook. Almost all of the project's code, both front end and back end, was written by Claude and GPT. To keep that from turning into chaos, the repository has rules for AI agents: how the project is structured, what to check, and what not to touch. Every change goes through the linter, server tests and browser scenarios on synthetic data. Anything involving medical data, Match rules or authentication is treated as a high-risk area and checked separately.

Costs

If you haven't noticed yet, saving money is the thread running through this whole story. Here's everything we pay for each month, including the tools we use to build the product.

Service	What for	Now
Google Cloud Run and Cloud Scheduler	server, registry sync, weekly digest	$0
MongoDB Atlas, Flex tier	registry copy, users, medical cards	$8
OpenAI, gpt-4o-mini	search plan, filling in cards, diagnosis translation	$1–5
Google Maps	geocoding and the trial site map	$0
Prelude	phone number verification	$1–3
Cloudflare Workers Paid	sending emails	$5
Domain	you get the idea	$2
PostHog	product analytics	$0
ClinicalTrials.gov API, NLM Clinical Tables, Photon	data and autocomplete	$0
Claude, 2 subscriptions	development	$40
Figma, 1 seat	design	$16

Total: about $80 a month right now. At 1,000 users, about $120–145.

Unsurprisingly, tools are currently our biggest expense. But here's the funny part: at 1,000 users, the biggest line item isn't tools, servers or even the model. It's phone verification.

MVP, testing and plans

The MVP is live and fully working. It already has the entire core feature set we planned for launch.

First tests

We've launched unmoderated usability testing. It's still running, but the first insights are already in.

One example: the handy features need to be front and center from the very first screen. Medical cards, Match and easy applications are all there, but someone who came "just to browse" can miss them and leave thinking it's just another catalog. Onboarding was already on our roadmap, and now real users have confirmed we need it.

Plans

Our plans follow the same personas from discovery, just one at a time:

Onboarding. Show right away how we differ from a regular registry search.
Volunteer dashboard. Healthy volunteers are a separate audience with their own needs, and they deserve their own flow.
The business side, plus dashboards for pharma and doctors. It only makes sense to approach them once we have a user base: without patients, we have nothing to offer researchers.

Takeaways?

Honestly, all I really wanted in this article was to plug our service. Fine, I'll share a couple of thoughts after all this work. I'll keep it short.

In my humble opinion, we've built a really solid product that tackles our main audience's pain points. It's stable, it looks good, and there's a roadmap. What more could you want? Monetization! But that's a whole other story, maybe for a future article.

And most importantly, cheesy as it may sound: if this makes it even a little faster for people in need to find a trial that suits them better, that's mission accomplished.

You can judge whether we pulled it off here: cintarra.com.

DEV Community: Mike Guskov