The Doctor in the Codebase: How AI Is Changing Who Builds Medical Software

For most of medical history, a physician who wanted software either hired someone to build it or did without. Building a telehealth platform that actually holds up in production is not a weekend project: it needs eligibility screening, secure patient messaging, prescription workflows, payment, audit logging, and cloud infrastructure that meets HIPAA. That was a job for a funded company, not a practicing doctor.

That is changing. AI-assisted development has collapsed the cost of building medical software to the point where a single physician can design, build, and run the platform their patients actually use. Not a prototype or a demo. Production software handling real visits, real prescriptions, and real patient data.

Dr. Ben Soffer is one of those physicians. He runs two telehealth practices, Discreet Ketamine and Tovani Health, and he builds and maintains the software behind both of them himself.

"Five years ago, 'a physician who ships code' was a contradiction. Building a compliant telehealth platform meant hiring a dev shop, waiting six months, and getting back something that half-worked. Now I build it myself, usually at night, and it's live the next morning. AI is the entire reason that sentence makes sense."

What a telehealth platform actually takes

To a patient, telehealth looks like a booking page and a video call. Beneath that surface is the part nobody sees. A new patient has to be screened for eligibility against real clinical criteria. Their identity has to be verified. Messages have to reach them by text and email without ever exposing protected health information. Prescriptions have to route to the right pharmacy with the right approvals. Reminders have to fire on schedule, and they have to fail safely, because a reminder that silently doesn't send is a patient who misses a dose.

Reliability is its own discipline. A consumer app that drops a notification loses an impression. A medical platform that drops one can cost a patient their refill, so messaging has to be built with redundancy: if the primary channel fails, a second one has to catch it, and every attempt has to be logged so a human can see exactly what happened and when. None of that is visible on the booking page, and all of it is the difference between software you can safely put in front of someone's health and software you cannot.

Every one of those pieces is a place where a bug is not an inconvenience. It is a patient who does not get care. Historically, each feature was a developer-month, which is exactly why small practices never built their own software and settled for whatever a vendor sold them.

The invisible, compliant scaffolding

The popular anxiety about AI in medicine is that a model will say something wrong to a patient. Soffer argues that on a well-built platform, that scenario simply never comes up, and the real engineering is somewhere far less glamorous.

"Everyone worries about the model saying the wrong thing to a patient. On my platforms it never talks to a patient unsupervised. The real work is boring and invisible: HIPAA boundaries, audit trails, making sure a text with someone's health information physically cannot leak. AI helps me build that scaffolding faster, but I'm the one who signs off on every piece of it."

This is the unglamorous majority of medical software, the compliance and safety plumbing that never appears in a feature list but determines whether a platform can be trusted with a patient at all. It is also precisely the kind of repetitive, pattern-heavy engineering that AI accelerates well: wiring an audit log, enforcing a data boundary, building the redundant notification path so an alert never quietly dies.

There is a reason a physician tends to get this part right. Doctors are trained to think in terms of what happens when something fails, because in medicine something eventually does. That instinct, applied to software, is exactly what compliance engineering rewards. The question is never only what the system does when it works. It is what it does when a message bounces, a payment fails, or a server restarts in the middle of an intake.

A one-person engineering department

The larger shift is economic. Work that used to require a team of engineers can now be done by one physician with an AI pair sitting next to them. Eligibility logic, appointment reminders, intake flows, the messaging system: built in evenings, in production the next day.

What makes that hold up is not the AI on its own. It is that the person directing it understands the medicine. A contractor building an eligibility flow is guessing at the clinical intent. A physician building the same flow knows exactly what a patient needs at each step, and uses AI to turn that judgment into working software instead of a specification document handed to someone else.

"The code was never the hard part for me. The hard part is knowing what happens if a reminder fires an hour late, or what someone with treatment-resistant depression needs to see before their first visit. AI took over the parts that were slowing me down and left me the part that actually needs a doctor. That is the right division of labor, and it took me a while to trust it."

It does not make the physician infallible, and it does not make the software write itself. It changes the ratio. The hours that used to go into translating clinical intent into a specification, handing it off, waiting, reviewing what came back, and correcting the misunderstandings now collapse into a single person moving between the medicine and the code without losing anything in the handoff.

Building in the open

Soffer has started documenting the process publicly, partly as a record and partly because very few people are showing what it actually looks like for a practicing doctor to build production medical software. The write-ups at drbensoffer.com/build walk through the real decisions: which parts of a telehealth stack are safe to let AI accelerate, which parts demand a physician's direct attention, and where the compliance lines fall.

The through-line is that none of this requires a computer-science degree. It requires knowing the medicine cold, a willingness to learn how the pieces of software fit together, and the judgment to know which of those two matters more at any given step. For a generation of physicians who have quietly resented the software imposed on them, that is a meaningful shift in who holds the pen.

Care built the way it's practiced

The interesting change here is not AI replacing doctors, and it is not AI replacing engineers. It is that the person who understands the medicine can now also build the software, without a translation layer of product managers and contractors standing between the clinical idea and the running code.

Buy medical software off the shelf and you inherit someone else's idea of how care should work. Build it yourself and it can be shaped around how you actually practice. For most of history that choice was only available to large hospital systems with the budget to match. AI is what puts it within reach of a single physician who is willing to learn to build, and it is quietly changing what a small practice can offer its patients.

---

Dr. Ben Soffer is a physician and software builder. He operates the telehealth practices Discreet Ketamine and Tovani Health, and a concierge primary care practice at drbensoffer.com. He writes about building medical software at drbensoffer.com/build.