Guide · for owners in health and therapy
Is Lovable HIPAA Compliant?
William Belle — Cloud Deployment and Software Engineering Questions: support@williambelle.co
The short answer is that no build tool is, and none can be. Not Lovable, not Replit, not Bolt, not Cursor. That sounds like bad news and it is not. It just means the question has a different shape than it first appears, and the parts that actually decide the answer are parts you control.
This guide explains what HIPAA applies to, what your build tool has to do with it, and what you can check about your own app this week.
Why the question does not quite work
HIPAA applies to organizations and the people they hire, not to software. A therapy practice can fall under it. A billing company working for that practice can fall under it. A text editor cannot, and neither can the tool you described your app to.
So a tool cannot be HIPAA compliant in the way a fire extinguisher can be certified. What a vendor can do is sign a Business Associate Agreement, usually shortened to BAA. That is a contract in which a company handling protected health records on your behalf agrees to protect it and accepts responsibility if it does not.
That reframes the question into one you can actually answer:
Which of the companies touching my patients' information have signed a BAA with me, and does what I have built meet the technical rules?
Your build tool is usually not on that list, for a reason worth understanding.
Where your build tool sits
There is a difference between the tool that wrote your app and the place your app runs.
If you describe an appointment app to Lovable and it writes the code, that code is just text. It has no patient data in it. At that moment nothing has happened that HIPAA cares about.
The moment that matters is when your app goes live and a real person's information goes into it. From then on, the companies that hold, move or process that information are the ones you need agreements with:
- Wherever the app itself runs
- Wherever the database sits
- Whoever sends your email and text messages
- Wherever files and uploads are stored
- Anything else the app sends records to
Many owners deploy straight onto their build tool's own hosting, because it is one button. That is the point where the tool stops being an editor and starts being a company holding patient information. Whether that is workable depends on what that vendor offers, on which plan, and whether they will sign a BAA with a practice your size.
Check that directly with the vendor before you assume either way. Ask one plain question: will you sign a Business Associate Agreement with me, on the plan I am on? A yes or no answer to that is worth more than any amount of reading.
If the answer is no, the fix is not to abandon what you built. The code is fine. It moves to cloud accounts in your own name, where the provider will sign, and it keeps working exactly as it did.
What actually decides it
Four things, and none of them are about which tool wrote the code.
1. Where the records live, and who has signed for them. Covered above. This is the one people miss, and it is the one a customer or a regulator asks about first.
2. Whether the data is unreadable to anyone who takes it. Records have to be scrambled where they are stored and while they travel between your users and the app. Modern hosting gives you the second one almost for free. The first one is a setting, and it is often off by default.
3. Whether the right people, and only the right people, can reach a record. Getting a sign-in page working is easy, and AI tools do it well. Making sure one client cannot load another client's notes by changing a number in the address bar is a different job, and it is the single most common serious flaw I find in apps built this way. A second step at sign-in for staff belongs here too.
4. Whether you can show what you did. This is the part almost nobody has. Being ready to meet the rules is not only a state your app is in, it is something you can produce evidence of when asked. A written record of what was configured, when, and by whom.
What you can check this week, without hiring anyone
None of this needs a consultant, and it will tell you where you stand.
- Ask your hosting vendor about a BAA, in writing, and keep the reply.
- Try to reach someone else's record. Sign in as a test user, find the address of a record that belongs to a different user, and put it in your browser. If it loads, stop reading and fix that first.
- Check your app is only reachable over a secure connection. Type your address with
http://in front instead ofhttps://. It should refuse or redirect, not load. - Find out where your database is. If you cannot answer where your patients' records physically sit, that is the honest starting point.
- Look for passwords written into your code. Search your project for the word
passwordand for anything that looks like a long random key. Those belong in a locked store, not in the code. - Write down who has access to what. Not a system, just a list. You will need it either way.
What stays yours, whoever you hire
Worth being clear, because some people will tell you otherwise. Being ready to meet the rules is not only a technical question, and no engineer can hand you all of it.
What an engineer can do: configure the app and the cloud it runs on to meet the technical rules, arrange the agreements your providers have to sign, and produce the written evidence that it was done.
What stays with you: your written policies, training your staff, naming the person responsible in your practice, your ongoing review of what could go wrong, and the statement you sign. Anyone who tells you they can take those off your hands is selling you something that does not exist.
Where this usually lands
Most owners I talk to are in better shape than they feared on the code and worse shape than they hoped on the deployment. The app works. It is running somewhere nobody has signed for, the database is reachable from the open internet, and there is no written record of any of it.
That is a few days of work, not a rebuild, and it does not mean starting over with what you built.
Get a free 20-minute review — show me what you have and I'll tell you the first three things I'd fix in it, and why. No pitch, and nothing to prepare.