The SaaS Trap in Healthcare
One thing to settle before you read further. Some of what follows assumes you hold a clinical license and are operating within your scope. If you do not, the educational and administrative builds in this post are still yours to make, but anything that interprets a lab value or recommends a therapy is not, no matter how easy the tool makes it look. Scope of practice does not expand because the code got cheap. This post is general information, not medical advice or legal advice.
If you run a health or wellness practice, you likely pay for three to five different software subscriptions: one for booking, one for forms, one for course delivery, and one for client communication. None of them talk to each other perfectly, and none of them fit your exact clinical methodology.
Until recently, the only alternative was paying a development agency $30,000 to build a custom app. In 2026, vibe coding changes that math.
What Healthcare Professionals Can Build With Vibe Coding
Vibe coding (using AI to write code via plain English instructions) allows non-technical practitioners to build a working prototype in a weekend. Getting that prototype to something safe enough for a patient to touch takes longer, and the difference is testing, review, and knowing which side of the FDA device line you are on. Here are three things you can build right now:
1. Custom Intake Routers
Instead of a generic Google Form, you can build a dynamic intake app that routes inquiries to the right destination. Understand what you are signing up for first. The moment your app receives a clinical inquiry, your app, your database host and any AI API it calls are creating, receiving and transmitting PHI on your behalf, which is the HHS definition of a business associate, and each of those vendors needs an executed BAA before you send them anything. If you do not want that footprint, build the router so it collects a name and a callback preference only, sends nothing clinical through the app, and hands the patient off to your covered channel for anything else.
2. Patient Progress Dashboards
If you teach a specific protocol (like a 30-day elimination diet), you can build a web app where patients log their daily adherence. Stay inside the line FDA draws in its general wellness policy: track the behaviour, not the disease. Logging and charting what someone did is general wellness. Adding a threshold that flags a value as out of range, or text that tells the patient what to do next, is not, and FDA's clinical decision support guidance says outright that software giving recommendations to patients rather than to clinicians meets the device definition. The alert feature is the one your AI assistant will happily add when you ask it to make the dashboard more useful. Do not accept it. You can have the AI generate Chart.js graphs so patients can see their own progress.
3. An Internal Reference Library
You can build an internal reference library that stores your own clinical notes, your preferred brands and your standard patient handouts, and lets you search them fast.
What you should not build with a weekend of vibe coding is a tool that takes a patient's lab markers and symptoms and returns a specific supplement protocol. Software that analyses lab values and outputs a specific treatment directive fails the criteria in section 520(o)(1)(E) that keep clinical decision support software outside the FDA definition of a device, and FDA's mobile medical applications guidance treats patient specific analysis that produces a treatment plan as software it actively regulates. That is a regulated device, not a productivity tool. Read FDA's clinical decision support guidance before you write a single prompt in this direction.
Whatever you do build, write down the answer to one question before you ship: what happens when this is wrong? For anything touching supplements, dosing or a clinical threshold, the honest answer is usually that a patient gets hurt and you do not find out. NIH's Office of Dietary Supplements documents dose dependent harm and real drug interactions, vitamin K against warfarin and St John's wort against antidepressants among them, and no rules engine an AI writes from your notes is going to catch those. If you cannot name the failure mode, the detection method, and the licensed person who reviews every output before a patient sees it, you are not ready.
The Two Risks
There are two risks in vibe coding for healthcare, and they are not equal. The first is patient harm: a tool that scores, triages or advises can be confidently wrong, and the patient absorbs that error. The second is regulatory: HIPAA if you are a covered entity or a business associate, the FTC Health Breach Notification Rule if you are a wellness business that is not covered by HIPAA but still holds identifying health information. AI coding assistants do not know either body of law. If you tell an AI to "build a database to store patient lab results," it will gladly build an unsecured, non-compliant database.
The rule: Use vibe coding for content that is not tied to an identifiable person: your educational library, your public pages, your internal reference material. Do not assume "administrative" means "not PHI". Under 45 CFR 160.103, protected health information covers anything individually identifiable that relates to a person's health, to the care they receive, or to payment for that care, so names on an appointment list and answers on an intake form are PHI when your practice holds them, not just labs and diagnoses. Records, labs, diagnoses and anything that identifies a patient belong in an environment you have an executed business associate agreement for. Google Workspace can be that environment, but it is not that by default: a super administrator has to accept Google's Business Associate Amendment in the Admin console, and even then coverage reaches only the services on Google's HIPAA Included Functionality list. No signed BAA means no PHI in Workspace, full stop (Lane 2).
Getting Started
You do not need to learn Python or React. You do need a `CLAUDE.md` file that defines your app's purpose, your architecture rules and your compliance constraints, and you need to accept that the file is an instruction, not a guardrail. An AI assistant can quietly break its own rules, and if you cannot read the code you will not see it happen.
So before anything you built this way touches a patient: have a developer read the code, test it against cases where you already know the right answer, confirm nothing clinical is stored where you did not intend, and roll it out to a handful of people before everyone. You act as the clinical director. A clinical director does not ship an intervention without checking it.