We Need to Talk About Your Vibe Coded Clinical Product
Understanding Technology Readiness Levels in the age of vibes ✌️
This is Clinical Product Thinking 🧠, your weekly newsletter featuring practical tips, frameworks and strategies from the frontlines of clinical product.
Good afternoon friends, this is issue No. 026. This week, we’re talking about clinical vibe coding and why and when it’s useful.
Over the past few weeks, I’ve had the pleasure of teaching at Bitelabs, where the cohort are about to start building their first healthtech products, as well as judging a startup competition with More than Medics, where teams presented genuinely beautiful clinical product prototypes.
These events brought to mind one of the most useful conversations I’ve had recently with Mike Pogose, Director of Quality Assurance and Regulatory Affairs at Hardian Health.
He described a pattern he’s seeing more and more: clinicians building thoughtful, impressive vibe-coded solutions and understandably feeling they’re close to certification, when in reality they’re still at the prototype stage.
This isn’t a judgement. It’s a misunderstanding, accelerated by the power of the tools we’re using.
We now live in a world where something can look production-ready long before it is mature.
Which is why clinical product leaders need to understand the basics of Technology Readiness Levels (TRLs) and what they mean for product maturity.
What Are Technology Readiness Levels?
Technology Readiness Levels were originally developed by NASA to assess whether a technology that worked in a lab was actually ready to operate in space.
They’re not a regulatory framework. They’re a maturity framework.
TRLs are now widely used across aerospace, defence, advanced engineering and publicly funded R&D to describe how developed a technology really is.
In simplified terms:
TRL 1–3 → Early concepts and prototypes
TRL 4–6 → Development, validation, early real-world testing
TRL 7–8 → Demonstrated in operational environments, certification-ready
TRL 9 → Fully operational with post-market surveillance
They answer one question:
How mature is this technology, really?
Not:
Is it legally approved?
That’s regulation.
TRL is about engineering and operational maturity.
The Vibe Coding Distortion
Large language models have changed the visual and experiential bar.
You can now:
Generate polished user interfaces
Create clinically coherent-seeming logic
Draft documentation in minutes
Simulate a security posture
I’ve seen this repeatedly. The prototypes look genuinely impressive. But impressive is not the same as mature.
Most vibe-coded solutions sit firmly at TRL 1–3. And that’s fine.
TRL 2 is where ideas belong when they’re being explored.
What’s dangerous is mistaking:
“Ready to explore”
for
“Ready to certify”
or worse
“Ready for patients.”
What TRL 1–3 Usually Means in Practice
At TRL 1–3 you typically still lack:
Robust, production-grade software architecture
Deterministic behaviour under edge cases
Validated and tested risk controls
Traceability from requirements → hazards → mitigations
A defensible clinical safety case
The logic might work. The UI might be elegant. But the foundations are not yet there.
“But It’s Just a Simple Tool…”
A common response is:
“It’s just a dosage calculator.”
“It’s only being used inside a hospital.”
“We’re not selling it.”
Even then, the bar is high.
The moment a tool influences clinical decision-making, you are in high-consequence territory.
TRL ≠ Certification Readiness
This is the distinction many teams miss.
Being ready to plan certification is not the same as being ready for certification.
At TRL 1–3 you should be asking:
Is this problem worth solving?
Does this intervention make clinical sense?
What would the regulatory pathway look like if we pursued this properly?
You should not be expecting:
CE or UKCA marking
FDA clearance
Or serious regulatory engagement beyond exploratory conversations
That work typically belongs much later, once the system has been deliberately engineered, tested and governed.
The Refactoring Fantasy
There’s another myth:
“We’ll just refactor it later.”
Refactoring is the process of restructuring existing code to improve its architecture, safety and maintainability without changing what it does.
In theory, yes, you could ask an engineer to refactor your vibe code base. But in practice, this usually means:
Rewriting large parts of the codebase
Untangling logic never designed for audit
Retrofitting safety and maintainability
Asking engineers to take ownership of decisions they didn’t make
Often, the prototype is quietly abandoned and rebuilt. Which can be painful if expectations weren’t set correctly.
Why This Matters for Clinical Product Managers
This is where clinical product judgement becomes critical. Your role isn’t to dampen innovation.
It’s to place it accurately on the maturity curve.
A strong CPM can say:
“This is still in prototype stage, excellent for learning, not for patients.”
“This is promising, but we are realistically 12 - 18 months from certification.”
“This needs proper engineering input before we discuss regulatory strategy.”
That clarity protects:
Patients
Teams
Founders
And your own credibility
Because nothing erodes trust faster than overselling maturity in a safety-critical domain.
The Bottom Line
I’m personally incredibly excited by vibe coding tools and with Lovable recently raising $330m they are surely here to stay. While they are a powerful accelerator for early-stage exploration, clinical product maturity cannot be vibe-based.
Technology Readiness Levels give us a language to separate:
What looks real
from
What is ready
And in healthcare, that distinction matters a lot.
If your product lives at TRL 3, that’s not a bad thing. It’s the right place to start.
Just don’t mistake it for something it isn’t.
Join Us at HLTH Europe 🇪🇺
Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.
👉 Register your interest for the panel here.
🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)
Clinical Product Drinks ✨
📆 25th March, 6:30pm, The Folly.
Join for a drink with other folks at the front line of clinical product. This is an informal evening to mingle and share experiences. No agenda, no panel or slides. 👉 Get your ticket here.
Hiring Spotlight x 2 🚀🚀🚀
1️⃣ CareADHD
CareADHD are hiring a Clinical Product Manager, an exciting opportunity to help shape product strategy inside a fast-growing, specialist digital clinic delivering ADHD care. This role sits at the intersection of clinical governance, patient experience and scalable product delivery, translating complex care pathways into robust, patient-safe systems. If you’re a clinician or clinical product thinker who wants to build responsibly in a high-growth environment, this is a serious opportunity. 👉 Apply here.
2️⃣ AIBody:
AIBODY are hiring a Clinical Product Owner, a genuinely hybrid role at the intersection of clinical governance, product ownership and real-world deployment. You’ll translate complex physiology and clinical workflows into product features and lead rollouts into live clinics. If you’re a clinician who wants to move beyond advisory into true product ownership, balancing safety, usability and adoption in a high-complexity environment, this is a serious build role. 👉 JD is here. Please contact the team directly.
That’s the public post for this week. See you next time! 👋
🤝 Work with me | 📅 Attend an event | | ✍️ Send a message
Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.
Made with 💜 for better, safer HealthTech.
[NEW] Want to Go Deeper? 👇 Join Paid
One of the biggest reasons Clinical Product Managers don’t get the cut-through they deserve isn’t capability, it’s commercial fluency. If you can’t confidently speak in terms of CAC, LTV, margin, runway or procurement dynamics, you risk being positioned as clinical support rather than strategic leadership. So I’ve created a 50-term Commercial Cheat Sheet for CPMs, the core vocabulary you need to operate credibly at C-suite level. It’s available below for paid subscribers. 👇
