Clinician Builder - A physician who finds the real clinical problem — and then builds the fix.
Most clinical products fail in the gap between the people who know the care and the people who build the software. I work on both sides of it: I use clinical experience to get the requirements right, then execute against them — building the product myself, or with a small team of engineers I trust.
Take it end to end, or bring me in for the one part you’re missing.
What I do - Three parts. Take one, or all of them.
Each part stands on its own. Together they are one engagement, from the first conversation with a clinician to software they use every day.
01
Find the real problem, and write the requirements
A clinician asks for another field. The useful question is what they were trying to decide.
I sit with the clinicians and care teams who use the tools every day, and separate a workflow problem from a training problem from a content problem. I read how a workflow actually runs today, decide what carries forward and what was never a real requirement, and make sure nothing a clinician relies on disappears along the way.
What you get
- A clear statement of the problem worth solving, and why
- Prioritized requirements, with what is out of scope said out loud
- A clickable prototype engineers can build from, not a document to interpret
- The measure that will show whether the fix worked
02
Navigate the regulatory and clinical-safety path
Whether a clinical feature is a regulated medical device is often decided by design choices made in the first weeks.
What the software recommends, who acts on it, and whether a clinician can see and independently review the basis for it all bear on where a product sits under the FDA’s software-as-a-medical-device and clinical-decision-support framework. I assess that early, shape intended use and design to fit the path you choose, and write clinical safety — human review, evidence behind every recommendation, PHI boundaries — into the requirements rather than bolting it on later. For submissions, I work alongside your regulatory counsel.
What you get
- An assessment of where the product sits, with the reasoning
- Design and intended-use recommendations for the path you choose
- The clinical risks, and the safety requirements that address them
03
Build it
Clinical judgment and taste are the hard parts of a clinical product. The code no longer has to be the bottleneck.
I build with agentic coding tools — moving fast where speed is safe, and checking every line of anything a clinician will act on. For larger builds I bring a small team of engineers I have worked with and trust, which puts senior clinical and technical judgment on the work at a lower cost than staffing it in-house. Or I hand your own engineers a working prototype, so they can see exactly what it should do.
What you get
- Working software, built against the requirements above
- Or a working prototype your engineers build from
- Safety and PHI requirements carried through to production
End to end - One person who owns the clinician’s side, from problem to production.
No hand-off between the person who understood the problem and the person who built the answer — because they’re the same person.
01
Listen where the care happens
Time with the clinicians and care teams, on their tools, after real visits.
02
Separate the request from the problem
Name the decision the clinician is trying to make, and what is getting in the way.
03
Check the path
Settle the clinical-safety and regulatory constraints before they become rework.
04
Show, don’t spec
A prototype the clinicians can react to and the engineers can build from.
05
Build, then measure what changed
Ship it, and check against the measure agreed at the start — not what shipped, but what changed for patients and clinicians.
Who it’s for - Teams where the clinical detail decides whether the product works.
- Care delivery organizations. Primary, home-based, virtual or complex care teams whose clinicians depend on today’s tools every morning — and who need someone to own the clinician’s side of the product without a PM or design layer.
- Health-tech companies building clinical AI. Teams putting AI in front of clinicians or patients who need the requirements and the regulatory and safety path right before engineering budget is committed.
- Teams mid-migration. Moving workflows between an EHR, a CRM and something new — where every workflow has a clinical version, and nothing a clinician relies on can be lost in the move.