Almost every health-tech founder I meet has a demo that works. The model classifies the image, flags the risk, transcribes the note. It works in the notebook, it works in the pitch, and it convinces a room full of smart people that the hard part is done.

It isn't. In my experience, a working model is maybe twenty percent of the journey to a product clinicians and patients can actually depend on. The other eighty percent is everything the demo quietly skips — and it's where most health-tech AI quietly stalls.

The demo lies by omission

A prototype is allowed to assume a clean input, a forgiving user, and a single happy path. Production isn't. The moment real clinicians touch your product, you inherit the messy data they actually generate, the edge cases nobody scripted, and the regulatory weight of being part of someone's care.

The gap between those two worlds doesn't show up on a slide. It shows up three months later, when the model that scored 0.94 in validation behaves unpredictably on a new clinic's data, and nobody can explain why because the pipeline was never built to be observed.

The hard part of health-tech AI was never the model. It's everything you have to build around the model so you can trust it on a Tuesday afternoon in a real clinic.

What the other 80% actually is

When I led engineering and data teams taking clinical AI to enterprise customers, the work that determined whether we shipped looked nothing like the work that produced the prototype. It was:

  • Data foundations. Reliable pipelines, versioned datasets, and the governance to know exactly what trained which model — because in healthcare, "I'm not sure where that number came from" is not an acceptable answer.
  • MLOps. The ability to deploy, monitor, and roll back models the way you would any other production system, with alerts when behaviour drifts instead of discovering it from a customer.
  • Compliance as architecture. HIPAA, PIPEDA, SOC 2, ISO 27001 — these aren't a checklist you bolt on at the end. They're constraints that shape your data model from day one, and retrofitting them is brutal.
  • Product discipline. Knowing which problem is actually worth solving, scoping it so the whole feature ships rather than a fragile slice, and resisting the pull to chase model accuracy past the point of clinical usefulness.

Why teams get stuck

The usual reason isn't a lack of talent. It's that the people who built the prototype — brilliant data scientists and engineers — are now being asked to do an entirely different job, often for the first time, while still shipping. Leadership ends up dragged into the details of every feature because the practices that would let the team operate independently don't exist yet.

That's a predictable phase, not a failure. Companies grow faster than their processes. The trap is treating a foundations problem as a hiring problem, or a hiring problem as a foundations problem, and solving the wrong one.

Plan for production on day one

You don't need to build all of this before you build anything — that's its own failure mode. But you do need to make deliberate decisions early about what you'll defer and why. A few that pay off repeatedly:

  • Decide what "production-ready" means for your risk profile before you start, not after a customer asks.
  • Instrument the prototype enough that you can observe it. A model you can't watch is a model you can't trust.
  • Write down the scope of a feature — including what you're intentionally not doing — so the gap between idea and shipped is visible and owned.
  • Treat compliance as a design input, not a launch blocker.

None of this is glamorous, and none of it demos well. But it's the difference between an AI that impresses in a pitch and an AI that earns a place in someone's care. The founders who internalize that early are the ones who get to production — and stay there.