Building your own clinic AI vs buying one

The reason build projects start is sound. Retrieval over documents is well-understood, the model providers have good APIs, and a developer can produce something that answers questions about your treatments in a weekend. That prototype is real and it works.

The distance between it and a system pointed at live patients is not mostly about AI. It is about everything around the AI.

What the prototype does not include

Channel infrastructure

• Meta business verification, Page connection and messaging permissions for Instagram and Messenger.
• WhatsApp Business Platform: provider selection, number migration, display name approval, template authoring and resubmission when they are rejected.
• The 24-hour window and the human-agent extension, handled correctly on each platform — they differ.
• Webhook delivery, retries, deduplication and ordering. Messages arrive twice, out of order, and occasionally not at all.
• Media: image download before the URL expires, voice note transcription, story and reel context resolution.

The safety layer

• A topic classifier that routes clinical content before the model produces anything — and an evaluation set proving it does.
• Abstention when retrieval returns nothing relevant, which is harder than it sounds because the model would rather answer.
• Handoff as a conversation state, so nothing automated fires into a thread a nurse has taken over.
• Regression testing, so that changing a prompt or upgrading a model does not silently move the clinical boundary. This is the part teams most often skip and most need.

The staff product

The thing nobody scopes. Your front desk needs a real inbox: a live queue, role-scoped access, the retrieved source visible beside each reply, mid-conversation takeover, patient history, and correct right-to-left rendering for mixed Arabic and English. This is a substantial application in its own right, and it is what your staff actually use all day.

Knowledge tooling

Someone non-technical has to author, review and expire cards, in two languages, with ownership and review dates. If that means editing a repository, it will not happen, and the knowledge base — which is the actual product — will rot within a quarter.

The operational tail

• Provider outages, rate limits, model deprecations and the migration each one forces.
• Cost control when a campaign triples volume overnight.
• Audit logging, retention enforcement, export, and per-role access review.
• Someone on call, because patients message at 3am and so do failures.

The honest checklist

Build if you can answer yes to all of these, today and in two years.

• We have at least one engineer who can own this as a product, not as a project with an end date.
• We are prepared to build and maintain a staff-facing inbox, not just an API.
• We can write and maintain a clinical evaluation suite, and run it on every model or prompt change.
• A non-technical clinic manager can author and expire knowledge cards without engineering help.
• We can absorb Meta platform changes — template policy, API versions, permission reviews — indefinitely.
• We have someone reachable when it breaks outside working hours.
• Our leadership understands this is a permanent line item, not a one-off build.

Groups with real engineering capacity and unusual requirements tick this list, and for them building is right — particularly where an existing internal system is the system of record and integration is the hard part.

The middle path

There is a third option that gets overlooked. Build the knowledge base yourself — properly, as described in building a knowledge base an AI can actually answer from — and buy the platform around it.

The knowledge base is the part that is genuinely yours, that carries your clinical judgement, and that improves your human front desk whether or not you ever deploy software. The channel plumbing, the safety layer and the staff inbox are commodity infrastructure that gets better by being shared across many clinics. Owning the first and renting the second is usually the right split — and it means your exit cost is low, provided the vendor exports.