Almost every health system I talk to has a team that wants to build its own AI tool.
Sometimes that's the right call. Usually it isn't — and the difference is predictable if you ask the right questions before anyone writes code.
The instinct to build is understandable. You know your workflows, you have the data, and a vendor quote looks expensive next to "we'll just have our team do it." But building clinical AI isn't a project, it's a commitment: to maintenance, monitoring, compliance, and the slow work of keeping a model useful after the people who built it have moved on.
What people underestimate about building
The model is the cheap part. What actually costs you is everything around it:
- Ongoing maintenance as models, APIs, and clinical guidelines change.
- Monitoring for drift, failure, and safety — forever, not just at launch.
- The full HIPAA and governance apparatus: BAAs, audit logging, access control, incident response.
- Integration with the EMR, which is almost always harder than anyone expects.
- The institutional knowledge that walks out the door when one engineer leaves.
A vendor amortizes all of that across many customers. Build it yourself and you carry it alone.
When buying is the right call
Buy when the use case is common, the problem is well understood across health systems, and several credible vendors already exist. Ambient documentation, coding support, inbox triage — these are crowded categories for a reason. Someone has already absorbed the cost of getting them production-ready and compliant. Re-building a commodity is paying twice for a worse result.
When building can make sense
Building is defensible when the workflow is genuinely specific to your institution and no vendor fits; when you have real, sustained engineering and ML capacity, not one enthusiastic team; when the use case is narrow enough to own and important enough to maintain for years; and when you can stand up the compliance and monitoring apparatus, not just the model.
Notice that most of those are about whether you can sustain the thing, not whether you can ship a first version. Shipping is easy now. Sustaining is the test.
The third option people forget: defer
Not every initiative needs a decision this quarter. Sometimes the honest answer is "wait" — the category is moving fast, prices are falling, and building now means locking yourself into today's tools. Deferring isn't indecision. In a fast-moving market, patience is sometimes the highest-return move.
How to decide
Ask three questions, in order. Is this a solved problem with credible vendors? If yes, buy. Is it specific and important enough that we'll maintain it for years, and do we have the capacity? If yes, build. Otherwise, defer — and put a date on when you'll revisit.
Most of the build-vs-buy mistakes I see aren't wrong answers. They're answers to the wrong question — "can we build this?" instead of "should we own this for the next five years?"
Prabhat Garg, M.D. is a practicing hospitalist and clinical AI strategy advisor. He helps health systems, health-tech companies, and investors decide what clinical AI to buy, build, avoid, and deploy.