Cursor, Lovable, Replit, Bolt, and Claude Code have made it genuinely possible for a doctor or a small team to build a working app in a weekend. Then someone asks "is it HIPAA compliant?" — and the honest answer is "the UI is fine; the part that matters isn't." Here's why, and what to actually do.
What HIPAA actually requires (the short version)
HIPAA isn't a checkbox in your frontend. It governs protected health information (PHI) and the vendors that touch it. The parts that bite a builder:
- Business Associate Agreements (BAAs). Every vendor that stores, processes, or transmits your PHI must sign a BAA taking on legal responsibility. No BAA, no PHI — full stop.
- Encryption at rest and in transit.
- Access control + audit. Minimum-necessary access, and a tamper-evident record of who saw or changed what.
- Breach notification obligations if it goes wrong.
Notice what these have in common: they live in the data layer and the vendor relationships — not the UI an AI tool is great at generating.
What AI coding tools do well
A lot, honestly. They scaffold the project, build the screens and forms, wire up state, and can even emit FHIR-shaped data models. For the workflow — the part a clinician actually pictures — vibe-coding is a real superpower. Keep doing it.
What they can't do — and quietly get wrong
- A BAA on the coding tool isn't a BAA for your app. Some will sign one (Cursor, on its Enterprise plan); many won't (Replit, Bolt, Copilot); and some — like Lovable — explicitly forbid PHI in their terms. But even when a tool signs a BAA, it covers the tool handling your code — not your running app's data. Every vendor your deployed app sends PHI to (your database, the model API, logging, analytics) needs its own BAA. A code generator can't produce that for you.
- They generate compliant-looking code. An AI will happily write a function named
encryptPHI()that base64-encodes a string, skip the audit log entirely, drop secrets into client-side code, or log PHI to the console. It looks done. It isn't. - They don't enforce access control. "Only a patient's own clinician can read their notes" is an authorization model someone has to design and enforce server-side. Scaffolded CRUD doesn't do it.
- They leak PHI to non-BAA services. Piping records into a model API, an analytics tool, or a logging service that hasn't signed a BAA is a violation — and it's the default in most generated code.
Does your coding tool sign a BAA?
This question only covers the tool processing your code — not your running app's data. Even so, the answers vary, and the defaults are mostly "no." Verify current terms yourself before sending anything resembling PHI through a tool.
| Coding tool | Default plan | Signs a BAA? |
|---|---|---|
| Cursor | Enterprise | Yes — on the Enterprise plan |
| Replit | Default | No |
| Bolt | Default | No |
| GitHub Copilot | Default | No |
| Lovable | Default | No — PHI forbidden in terms |
And again: a BAA on the tool that writes your code is not a BAA for the database, model API, or logging service your deployed app sends PHI to. Those are separate vendors with separate agreements.
Five compliant-looking-but-wrong patterns AI emits
These show up constantly in generated healthcare code. Each one passes a casual read and fails an audit:
- A fake
encryptPHI()that base64-encodes (or just hashes) a string and calls it encryption. - No audit log — reads and writes to PHI happen with no tamper-evident record of who did what.
- Secrets client-side — API keys or DB credentials shipped in the browser bundle where anyone can read them.
- PHI in
console.log— patient data dumped to logs that flow to a non-BAA log sink. - No server-side authorization — access checks live in the UI, so any caller hitting the API directly reads every patient.
Where does PHI actually go?
Trace one record through a typical vibe-coded app. Every hop that stores, processes, or transmits PHI needs its own BAA:
- Browser (your UI) — captures the data. Needs a BAA? No (it's the user's own device), but it must not persist or leak PHI.
- Your API server — receives and routes the data. Needs a BAA? Yes — the hosting/compute vendor.
- Your database — stores the record. Needs a BAA? Yes.
- Model API — summarizes or drafts from the record. Needs a BAA? Yes.
- Logs & analytics — anything PHI lands in. Needs a BAA? Yes if PHI reaches it — so keep PHI out, or use a BAA-covered sink.
So where's the line?
Vibe-code the workflow. Don't vibe-code the clinical data layer. The data layer is where PHI lives, where the BAA applies, where encryption and audit and access control have to be real and enforced — and where "generate me something" is exactly the wrong move.
The practical pattern: build your UI and workflow with whatever AI tool you love, on top of a clinical backend that handles the hard, regulated parts for you — runs in your cloud under your BAA (or a managed one that signs a BAA), with encryption, automatic audit + provenance, and per-patient authorization built in, and FHIR underneath for portability.
That's the gap bonfireDB is built for (open source, early access): the safe clinical data layer beneath the app you vibe-code. See the security & HIPAA model for how the BAA and data-residency story works, or FHIR explained for the data side.
Keep reading
TL;DR
- You can vibe-code the app. You cannot vibe-code HIPAA compliance.
- A BAA on your coding tool ≠ a compliant app — your app's data-layer vendors each need their own BAA, and the AI emits compliant-looking code that isn't (fake encryption, no audit, PHI in logs/prompts, no real access control).
- Compliance lives in the data layer + vendor relationships — keep those real.
- You build the app. Bonfire keeps the clinical data layer on infrastructure built for PHI.