What a $500M Software Engineer Sees When He Looks at a Functional Medicine Practice

When I walk into a functional medicine practice, I do not see what the owner sees. The owner sees patients, protocols, a schedule, a stack of charts. I see a production system, because that is what twenty years of software engineering trains you to see, and I spent those years building systems under load, including one application that went from zero to $500 million in revenue in four years.

I also spent fifteen years on the other side of the clipboard, as a functional medicine patient, watching the practices that helped my family run themselves in ways that would not survive a code review. So let me give you the audit. This is what an engineer sees in your practice, in the order the findings would appear in the report.

Finding one: a single point of failure, load-bearing, unbacked-up

Every system has components, and the first thing an engineer maps is what fails if each component fails. In your practice the map is short: nearly every function routes through one node. You. Diagnosis routes through you, but so do the patient education speech, the lab interpretation, the follow-up judgment, the marketing decisions, and most of the institutional memory, which exists only in your head.

In my industry we call this a single point of failure, and a system with one is classified as fragile no matter how well it is currently running. Uptime is not the test. The test is what happens under fault: your two-week illness, your family emergency, your eventual desire to sell. Engineers do not tolerate this design, not because failure is likely on any given day, but because failure is certain across enough days, and the cost of redundancy is always lower than the cost of the outage.

Finding two: the most expensive processor is running the cheapest jobs

Engineers obsess over what runs where. You do not schedule batch cleanup jobs on your most powerful, most expensive machine; every workload goes to the cheapest resource that can execute it correctly.

Your practice inverts this rule daily. The most expensive processor in the building, your clinical judgment, spends its cycles on transcription, scheduling logistics, repeated explanations, and form-shuffling: jobs a system or a $22-an-hour human could run identically. Meanwhile the workload only you can execute, judgment, waits in the queue behind the busywork. In computing we call this a scheduling failure. In your practice it is called Tuesday night charting.

Finding three: dormant data assets everywhere

An engineer inventories data the way an accountant inventories cash, and your practice is unknowingly rich. Years of patient records that encode which cases respond to which protocols. A dormant list of past patients, each one a pre-built trust relationship producing nothing. Protocols refined across hundreds of cases, existing nowhere but your memory. Testimonials sitting unread on a hard drive. Intake patterns that predict exactly what your next hundred patients will ask.

In software, data that exists but produces no value is called dark data, and finding it is a celebration, because activation costs a fraction of acquisition. Your dormant list alone is worth five figures a year. Your protocol knowledge is a product that has never been compiled. Nothing new needs to be created; the assets exist, idle, waiting for a system to run them.

Finding four: the expertise is unversioned and dies with the instance

Here is the finding that would stop a code review cold: the practice's core intellectual property, the way you think through a case, has no existence outside the original copy. It is not written down in executable form, not encoded into your intake, not embedded in tools, not transferable to a hire without years of apprenticeship. In engineering terms, your life's work is running in production with no source code, no documentation, and no backup.

The tragedy is not hypothetical. It plays out at every retirement, every burnout, every practice sale that values decades of refined judgment at the price of used exam tables. Expertise that structured, and yours is deeply structured, whether you can see it or not, can be encoded: into assessments, into decision-support tools, into education sequences, into systems that scale the judgment without cloning the doctor. Uncompiled, it is a rental. Compiled, it is an asset.

The part that is not a deficiency

An honest audit reports strengths, and this one is real: the clinical product is excellent. The medicine works, the patients who find you get well, the demand exists and is growing. Engineers rarely get handed a system whose core function is this sound. What is broken is everything wrapped around the core: distribution, capture, leverage, redundancy. And here is the professional secret that should make you optimistic: wrapper problems are the easy kind. I cannot teach anyone to reason through a complex case. Encoding, automating, and distributing the reasoning of someone who already can? That is a solved class of problem. That is just engineering.

The closing recommendation

Every audit ends with a recommendation, so here is mine. Stop treating these findings as personality flaws or time-management failures. They are architecture, and architecture can be rebuilt while the system keeps running, one component at a time: the highest-leverage failure first, then the next.

The doctrine I use to sequence that rebuild is the leverage doctrine, and the longer version of how an engineer ended up doing this work at all is here. The practice you have is a brilliant function trapped in a fragile system. The function is the hard part, and you already built it. The system is my part, and I have built harder ones.