The hiring mistake almost every clinician founder makes
You’ve raised your seed round. You’ve validated the clinical problem. You’re ready to build. So you do the obvious thing: you post for a senior ML engineer and a senior full-stack developer. Maybe a designer if you’re being thorough.
This is the team that built every B2B SaaS startup you’ve ever read about. It is the wrong team for a clinical AI product.
Not because those people aren’t talented — they usually are — but because the work of building a regulated clinical AI application requires a completely different distribution of skills. The team that ships a great consumer app will ship a clinical AI prototype that cannot be cleared, cannot be deployed, and cannot be defended in front of an FDA reviewer. They will do it cheerfully, on time, and with great test coverage.
This is the second post in our series on what makes medical AI startups structurally different. The first post covered why the work itself is different. This one is about who does the work.
What the conventional team gets wrong
A typical “senior ML engineer + senior full-stack” team optimizes for three things: model accuracy, shipping speed, and code quality. These are all good things. They are also insufficient.
Here is what that team will not do, by default, unless someone tells them to:
- Define an intended use statement before training a model. They will start with the data and let the model find what it can.
- Classify risk under ISO 14971 before architecting the system. They will design for performance and worry about safety later.
- Build a Design History File alongside the code. They will write great READMEs and zero traceability matrices.
- Plan a validation protocol before collecting validation data. They will report AUC on a random split and call it done.
- Document software lifecycle activities under IEC 62304. They will assume “we have tests” satisfies this. It does not.
- Track requirements to risks to mitigations. They will track issues in Linear.
None of this is a criticism of the engineers. It’s a criticism of the team composition. You hired people to build software. You needed people to build a regulated medical device that happens to be made of software. Those are different jobs.
What “regulatory-aware engineering” actually means
The right team for a clinical AI startup looks superficially similar to a normal startup team — same titles, often the same headcount — but every role is shaped differently:
The ML engineer isn’t just optimizing for AUC. They’re thinking about subgroup performance, calibration, drift, failure modes, and the explainability requirements that come with the intended use. They know that a model that is 2 points worse on AUC but 10 points better on calibration is the model that gets deployed.
The software engineer isn’t just shipping features. They’re building inside a software development lifecycle that maps to IEC 62304: requirements traced to design, design traced to code, code traced to tests, tests traced back to risks. They write a commit message and a DHF entry in the same motion.
The data engineer isn’t just moving data. They’re building lineage that survives audit: where did this row come from, under what consent, with what de-identification, validated by whom, on what date. The pipeline is the evidence.
The product designer isn’t just making the workflow nice. They’re applying human factors engineering — IEC 62366 — to ensure the user interface doesn’t introduce use-error risks that the regulatory submission has to mitigate.
The clinical lead isn’t a part-time advisor. They’re a full participant in the design decisions, because intended use is a clinical question, validation is a clinical question, and workflow fit is a clinical question.
You can find people who do each of these things. They are rarer and more expensive than generic equivalents. For most early-stage clinical AI startups, the correct move is not to hire all of them at once.
What to hire instead
The right early-stage team for most clinician-founded AI startups looks like this:
- A clinical founder (you) — full-time, owning intended use, clinical validation, and the relationship with the pilot site.
- One senior engineer who has shipped a regulated product before — not “knows about HIPAA,” not “worked at a healthtech company once.” Has actually worked inside an IEC 62304 lifecycle and can teach the rest of the team how to operate inside one. This person is rare. They are worth twice what you think.
- One ML engineer with healthcare experience — comfortable with calibration, subgroup analysis, and the difference between research metrics and clinical metrics.
- A fractional regulatory advisor — not a full-time hire. Someone who has been through a 510(k), reviews your intended use statement, and tells you when you’re about to make a risk-classification mistake.
- A fractional CAIO or technical co-founder — someone who connects all of the above into a coherent architecture and roadmap, holds the team to the lifecycle, and translates between clinical, regulatory, and engineering languages.
That’s it. Five people, two of them fractional. This team can take a clinical idea to a deployable, defensible, demo-able product.
What you don’t need yet: a designer (the fractional CAIO or the senior engineer can hold this), a DevOps hire (cloud-native templates do most of it), a separate data engineer (the ML engineer covers it at this scale), or a head of product (you are the head of product until you have customers).
The expensive lesson
Most clinician founders learn this the hard way. They hire a great team that ships a great prototype. The prototype gets clinical interest. Someone asks what the regulatory pathway is. The answer is uncertain. They bring in a regulatory consultant who takes one look at the architecture and tells them, gently, that none of it is auditable. Not the data lineage, not the model versioning, not the test traceability, not the design controls.
The prototype works. It just can’t be cleared.
Now they have a choice: rebuild from scratch with regulatory rigor (a year of runway, gone), or pivot to a “research tool” positioning (and watch the commercial path narrow). Most pick the rebuild. Some don’t survive it.
How GluonLabs thinks about hiring
We act as the fractional senior engineer + fractional CAIO for clinician-founded AI startups precisely because we’ve watched this movie too many times. Our first job in any engagement isn’t to write code — it’s to make sure the next engineer you hire is the right engineer, working inside the right lifecycle, on the right architecture, against the right intended use.
Sometimes that means we build the first version with you. Sometimes it means we coach the team you already have into a regulated lifecycle. Sometimes it means we tell you that your current MVP is unsalvageable and that the cheapest path forward is a structured rebuild — and then we help you do it without losing the clinical insight or the team.
In the next post, we’ll get into the third structural difference: why go-to-market for a medical AI product is unlike anything you’ve sold before, and why the most underrated investment a clinical AI startup can make is in education, not advertising.
GluonLabs is an engineering and product studio, not a regulatory consulting firm. We design and build clinical AI systems with regulatory frameworks (FDA, IEC 62304, ISO 14971, HIPAA) shaping our architectural and process decisions. Final regulatory strategy and submissions should be reviewed and signed off by a qualified regulatory professional.