Why AIn't Doctor?

There are now roughly three million companies that can “build an AI solution for your business.”

Some of them are excellent.

Some learned Claude Code last Tuesday.

The problem is that from the website it can be surprisingly difficult to tell which is which.

So I don’t think the useful question is, “Why is AIn’t Doctor the best healthcare AI company?”

There is no best healthcare AI company.

The useful question is: why would you use us instead of ChatGPT, a freelancer, your internal developer or another AI agency?

That I can answer.

Why not just use ChatGPT or Claude?

You can.

Seriously.

If you need to summarize non-sensitive documents, write emails, prepare marketing copy, classify something low-risk or solve another simple internal task, I am the last person who will tell you that you need a $30,000 custom AI project.

Open ChatGPT. Try it. You may already have the solution.

The problem starts when somebody says, “Great. Now let’s connect it to the EHR and let it talk to patients.”

That sentence changes everything.

Now we need to know what patient information goes into the model, who has permission to access it, where it is stored, which provider receives it, what happens when the model invents something, how conversations are audited, how the system identifies the patient, how it schedules an appointment, what happens when the EHR API is down, when it escalates to a human, which questions it is forbidden to answer, and whether we have just created regulated clinical software without realizing it.

The chatbot is the easy part. The system around the chatbot is the job.

“But I built a prototype myself and it works”

I believe you.

Modern AI tools are astonishing. A doctor or clinic owner with some technical skills can build something in a weekend now that would have required a development team several years ago.

That is fantastic.

The dangerous part is that the prototype can be very convincing. It answers 20 test questions. Everybody in the room says wow.

Then a real patient arrives.

They misspell the name, send a voice message, change languages halfway through the conversation and ask whether chest pain can wait until Monday. Meanwhile the scheduling API returns an error, the patient exists twice in the EHR, and the model confidently invents an available appointment.

Welcome to production.

I have seen plenty of clinic-built experiments and AI demos. The gap between “look what I made with Claude” and a system you can leave running with real patients is much larger than it appears from the demo screen.

Building the UI is no longer the hard part. Architecture, security, integration and getting the thing into real production are.

Doctors already use ChatGPT with patient information anyway

Yes.

I know.

A lot of them do.

That doesn’t magically make it a good data-governance policy.

When a doctor personally copies something into a public AI service, the clinic still needs to understand what information is being disclosed, under what legal and contractual framework, and with what safeguards.

The fact that “everybody does it” works very well right until the first serious complaint, security investigation or patient dispute.

There is another problem.

Patients themselves can get surprisingly good medical explanations from ChatGPT. Sometimes excellent ones.

The problem is not that everything it says is wrong. The problem is that the patient usually cannot identify which 5% is wrong.

A physician often can because the physician has the background to notice when the reasoning suddenly goes off the road.

Same thing with building AI. A clinic owner can make a very good prototype, but unless you know where production AI usually fails, you don’t know which problem you forgot to look for.

If you are building an AI that summarizes your internal emails, the risk is fairly low.

If you are stepping onto medical ground, it starts looking a little like an economist building ECG equipment.

Why not hire one good freelancer?

Again: you can.

For a simple project, I would not even argue with you. If you find a genuinely good freelancer who already understands healthcare and has built similar systems in your market, that may be the most efficient option.

The two important parts of that sentence are understands healthcare and similar systems.

Imagine you need somebody to advertise your medical clinic. You find a very good performance marketer. He previously promoted hotels.

There is a decent chance he can make the ads work.

There is also a decent chance he does something completely normal in hotel marketing that is illegal or unacceptable in healthcare advertising in your jurisdiction.

The freelancer wasn’t stupid.

He simply didn’t know what he didn’t know.

Healthcare software has exactly the same problem.

At some point one person isn’t enough

Take a more complicated project.

You need an AI system that talks to patients, reads existing medical information, integrates with the EHR, schedules appointments, produces structured clinical drafts and runs in your own infrastructure.

Now you may need somebody who understands the clinical workflow, plus backend development, frontend work, AI architecture, DevOps, security, QA, integration specialists, and possibly legal or regulatory advice.

And somebody has to make all these people deliver one system rather than eight technically excellent pieces that don’t work together.

It is a bit like a complicated medical case. There is nothing wrong with a GP, but sometimes you need the cardiologist, MRI, neurologist, endocrinologist and somebody coordinating the whole thing.

At some point one person is simply not the right structure.

The part everybody underestimates: what are we actually building?

This is where my clinic background matters more than my AI background.

Developers generally build what you ask them to build.

This sounds obvious.

It is also responsible for a huge percentage of failed software projects.

If you come to a developer and say, “I need an AI chatbot for patients,” congratulations: you have successfully described approximately 3% of the system.

These questions are not bureaucracy.

They are the product.

That is why our discovery process usually involves the people who actually do the work, not just management. Very often the first description of a workflow is not the real workflow.

I came into software from clinics, not the other way around

Before building healthcare technology, I spent years running healthcare businesses.

I personally launched more than 15 clinics, managed three and have been involved in developing or implementing healthcare IT in roughly 100 organizations.

I have sat on the other side of this table.

I have been the person asking why reception needs five people today, why the report isn’t ready, why doctors refuse to use the system, why we are paying for software nobody opens, why leads disappear, why the patient is standing at reception while three people look for their information, and why this “simple integration” has taken three months.

That experience is useful because clinic workflows are weird.

Every clinic believes its process is normal.

Then you compare ten clinics and discover ten completely different definitions of “normal.”

We’ve been doing healthcare AI since before ChatGPT made it fashionable

Our team started working around healthcare AI back in the IBM Watson era.

That is roughly a decade of watching the field repeatedly announce that doctors are about to become obsolete.

They remain stubbornly employed.

What did happen is more interesting.

Models became dramatically better at language. Speech became practical. Vision improved. Retrieval became much better. Infrastructure became cheaper. Integration became easier.

And suddenly a huge number of boring healthcare workflows became genuinely automatable.

That is the part I find interesting.

Not building a fake digital doctor.

Taking 40 repetitive actions performed by a doctor or receptionist every day and making 25 of them disappear.

That’s not theoretical — see the InnMap case study for what it looks like when we actually build one of these end to end, including the parts that broke first.

We don’t think AI should replace the doctor

The company is called AIn’t Doctor for a reason.

For clinically meaningful decisions we design around a physician being responsible for the medical judgment.

AI can collect information, organize it, retrieve relevant data, draft, summarize, compare, flag, calculate, prepare, ask, remind and automate.

It can make a doctor dramatically faster.

But current LLMs hallucinate. There is no architecture today that gives you a magical mathematical guarantee that a generative model will never produce false information.

You can reduce the risk with RAG, rules, ontologies, structured outputs, validation, source control, testing and human review.

You cannot make the nature of the technology disappear.

So we build around reality.

We also don’t believe every problem needs custom AI

Sometimes the answer to discovery is: use an existing SaaS product.

Sometimes: use ChatGPT.

Sometimes: automate this with ordinary software; AI adds nothing.

Sometimes your problem isn’t technical at all. Your workflow is broken.

I would much rather tell you that during the first free interview than sell you three months of development and discover it together afterward.

What are we actually good at?

We are strongest when the project has some combination of healthcare workflow complexity, legacy software, sensitive patient data, integrations, custom AI logic and a need to get the thing into actual daily use.

Not just make a demo.

We have experience across the US, Europe, Israel, the CIS and Asia, so we are used to the fact that clinic operations, infrastructure and regulations change by market.

We can handle the project from initial interviews and architecture through development, infrastructure, integrations, testing, implementation and support.

We build custom solutions because clinics really are different. But we don’t start every project from an empty Git repository either. We reuse proven components and patterns for common healthcare problems, which reduces the amount of expensive custom development required.

So when should you use AIn’t Doctor?

If all you need is a clever chatbot connected to a public API, you have cheaper options.

Use them.

If you already have an excellent internal product and AI team, you may not need us either.

Where we make sense is when you want somebody who can walk into the clinic, understand the workflow, understand the software, understand what AI can realistically do, identify where the nasty edge cases are hiding, and then take responsibility for getting the complete thing working.

Real staff. Real patients. Real medical data. Real legacy systems. And real consequences when something goes wrong.

That is a much less glamorous description than “revolutionizing healthcare through AI.”

I think it is also a better description of what we actually do.