A rejected app review costs you a launch window. A shipped intake tool that leaks a patient record costs you an OCR investigation, a breach notification clock, and the kind of headline a clinic doesn't recover from quickly. That's the price tag sitting under the pitch deck when a vendor shows up Monday morning with a working intake app their chatbot wrote over the weekend.
The demo compiles. The screens flow. Patients can tap through onboarding on an iPhone and the data lands somewhere. The question a healthcare buyer has to answer is whether "somewhere" is a place PHI is allowed to live, and whether the thing you're being shown is a product or a prototype wearing product clothing.
A Prompted Prototype and a Shippable App Are Not the Same Artifact
A prototype's job is to convince someone the idea is possible. A shippable clinical app's job is to behave correctly for every patient, on every device, through every failure mode, under a regulatory regime that doesn't care how clever the prompt was. Those are different artifacts, and the distance between them is where buyers get hurt.
Geek Vibes Nation spelled out what a weekend prompt leaves on the floor in its reporting on why a vibe-coded build is not a shippable app, covering the assumptions founders bring to the submission portal and the review checklists that dismantle them. The piece is written for consumer app teams. The lesson transfers straight to healthcare, where the review checklist you really need to pass isn't Apple's — it's your own compliance team's.
The Demo Shows the Happy Path. The Reviewer Checks the Rest
In the demo, the vendor types in a fake patient, taps through the form, and lands on a confirmation screen. Everyone claps. The parts no one saw are the parts that decide whether this thing is safe to put in front of a patient:
- Authentication and session handling. Prompted code frequently ships with login flows that look right and authorize wrong. A session that never expires on a shared tablet in a waiting room is a HIPAA incident waiting to happen.
- Authorization checks on every endpoint. The UI may hide a screen from a patient, but the API behind it often doesn't. Changing an ID in a URL and getting someone else's record back is a common AI-generated-code failure mode.
- Encryption in transit and at rest. A build can "work" while posting PHI over plain HTTP to a test bucket the vendor forgot to lock down.
- Logging and audit trails. If you can't produce an access log on request, you can't demonstrate compliance when someone asks.
Independent security research keeps landing on the same point. A Georgia Tech team scanning AI-generated repositories found dozens of confirmed vulnerabilities including command injection, authentication bypass, and server-side request forgery — the exact categories that turn an intake form into a data-exfiltration tool.
Buy-Then-Harden Looks Cheaper on Monday and Expensive by Friday
There are two ways to get the intake app in front of patients. The first is to accept the vendor's weekend build, sign the contract, and ask your team to "harden it later." The second is to treat the prototype as a spec, require a proper engineering pass before anything touches a real record, and pay for the delay up front.
The first path looks cheaper on Monday and tends to be the opposite by Friday. Retrofitting authentication, authorization, encryption, and audit logging onto a codebase that was rarely designed around them can cost more than building it correctly the first time, because every fix touches assumptions the prompt made without saying so. The second path is slower by weeks and can be faster by months.
The Paperwork Is Doing Work the Code Can't
Before any of this matters, the contract has to be right. Without a BAA in place, sharing PHI with a vendor creates a HIPAA violation regardless of how well their code is written. If the vendor is passing data through a third-party model provider, that provider needs its own BAA, and the agreement needs to say in plain language whether patient data can be used for training.
Ask for a current penetration test report, not a promise of one. Ask who owns the code if the vendor disappears. Ask what happens to PHI on day one after you terminate. The answers tell you whether you're buying a product or renting someone's weekend.
Experienced Engineers Have to Step Back In for the Last Mile
Prompted code is useful. It compresses the distance between an idea and a working screen in a way that genuinely helps small teams. The mistake is treating that compression as the whole job. In clinical software, the last mile — threat modeling, access control design, data minimization, breach response, dependency review, monitoring — is the part a model is not well suited to do for you, because it takes judgment about a specific clinic, a specific workflow, and a specific risk tolerance.
If the vendor can't tell you who on their team owns those decisions, you own them by default. Before the intake app touches a patient record, make sure someone qualified has read the code, not just watched the demo.
