How to Migrate From Lovable or Replit to a HIPAA-Compliant Stack

The prototype works. The demo went well, the screens look right, and somebody has just asked when the first real patient can use it. That question is where a vibe-coded side project stops being a side project, and where most founders discover that a HIPAA-compliant app migration is waiting for them.

‍

The usual framing is that a platform either is compliant or isn't, so the job is picking a compliant one. That framing is wrong, and it costs people months. Compliance isn't a property of a builder. It's a property of each component in your stack and the contract sitting behind that component, which means the answer differs layer by layer inside the same application.

‍

So this isn't a verdict on any one tool. Those have been written, including by us, and they stop where your problem starts. What follows is an inventory you can run against your own stack this afternoon: what you keep, what you re-contract, what you replace, and which safeguards stay yours regardless. The answer is usually less drastic than feared, and lands somewhere other than expected.

‍

‍

Can you move a healthcare app off Lovable or Replit onto HIPAA-ready infrastructure without rebuilding it from scratch?

Yes. Your product moves; the plumbing underneath it gets replaced. Go through your stack one layer at a time: keep what the vendor will cover in a contract, replace what it won't, and build the safeguards no vendor covers for you. Most of that work is mechanical. At Specode we start by reading your codebase, map what transfers and what has to change, then walk you through that plan before anyone touches anything.

‍

• The builder you prototyped on is usually the only component you cannot bring with you. Lovable's terms bar protected health information unless a separate agreement permits it, and Replit's published terms don't address it at all. The database, hosting, and auth underneath are a different question with different answers.
• A vendor's SOC 2 report answers a different question than a business associate agreement. Both builders publish security attestations; neither publishes a HIPAA offering. Only the agreement determines whether patient data may lawfully enter a system.
• The obligation follows your data down the whole vendor chain, not just to your first vendor. A subcontractor handling patient data on a business associate's behalf is itself a business associate. Inventory every service that touches the data, including the ones added in a hurry.
• Some safeguards are yours no matter which vendors you sign with. Audit controls and access control are standards in the rule as it stands today. No hosting agreement writes your audit trail or keeps patient identifiers out of your URLs.

‍

Why your platform blocks you before your code does

Before you scope the work, read your builder's terms of service. That's where you learn whether this is a technical or contractual problem.

‍

Usually it's contractual. The decision to migrate off Lovable or Replit rarely begins with your codebase: your screens, data model, and business logic aren't the problem.

‍

Most writing about Lovable HIPAA compliance and Replit HIPAA compliance stops at the verdict, covered in is Lovable HIPAA compliant, Replit's HIPAA position, and the same question for Bolt. When you're planning a move, the exact wording matters more.

‍

One distinction does most of the work here. An attestation describes how carefully a vendor runs its systems. An agreement establishes whether regulated data may enter them at all. A vendor can be rigorous and still have no contract that lets a patient record through the door.

‍

What Lovable's terms actually say

Lovable's terms of service, updated August 2026, say that unless your plan or a separate written agreement expressly permits it, you agree not to provide protected health information subject to HIPAA through the Services. The standard Services, they add, are "not designed to serve as a system of record" for it.

‍

That carve-out tells you what you'd be negotiating. The door is shut by default rather than sealed, and the standard product isn't the arrangement that opens it.

‍

Read one section further and a quieter problem shows up. Lovable's services run in part on infrastructure providers, Supabase among them. Absent an express written agreement, it doesn't guarantee which country your data is processed in. A footnote on a marketing site, a live question about a patient record.

‍

Lovable's security page says it supports SOC 2 and GDPR requirements and offers documentation for enterprise review. It publishes no HIPAA offering and no business associate agreement.

‍

What Replit's terms leave out

Replit's terms of service, updated August 2026, pose the opposite problem: no mention of HIPAA, protected health information, or business associate agreements. An absence is harder to act on than a prohibition, because there's nothing concrete to hand a reviewer.

‍

Those terms do reserve Replit's right "to access the content of your private apps" for troubleshooting and security. That's ordinary for a general-purpose development platform. It's also the access a signed agreement normally governs once that content is a patient record.

‍

Replit publishes a SOC 2 Type 2 attestation and runs on Google Cloud Platform. It publishes no HIPAA program.

‍

That last detail traps people. Google Cloud will sign agreements covering patient data, but that says nothing about the platform built on top of it. The certification doesn't travel up the stack.

‍

Where compliance actually lives in your stack

Once you accept that the blocker is contractual, the question changes shape. You stop asking whether a platform is compliant and start asking who signs what, for which service, and on what conditions.

‍

That turns the move into an inventory. Walk your stack layer by layer and give each component one of three verdicts: keep it where the vendor will cover it and you can meet their conditions, re-contract where coverage exists on a different plan or add-on, and replace whatever has no route into scope at all.

‍

Most teams find that HIPAA-compliant infrastructure is less a product you buy than a set of agreements you assemble, and that fewer layers need replacing than they feared.

Why every vendor in the chain is in scope

Before you can grade a layer, you need to know which layers count. All of them, in practice.

‍

A covered entity may let a business associate handle patient data on its behalf only after obtaining written assurances that the data will be safeguarded, documented in a business associate agreement. The same duty then runs downward: a subcontractor handling that data on the business associate's behalf is itself a business associate.

‍

So the obligation follows your data rather than stopping at whoever you signed with first. That includes the analytics tool someone wired in during a demo push, the email provider handling password resets, and the file storage nobody has looked at since.

‍

What each layer's vendor actually publishes

Here's how a typical vibe-coded stack grades out.

The conditions are the substance, not a footnote. Supabase documents both conditions: a signed agreement and the HIPAA add-on enabled, after which a project can be configured as high compliance. Self-hosted deployments stay out of scope entirely.

‍

Hosting works the same way, on different terms. Vercel signs agreements with eligible Pro and Enterprise customers, and for databases Neon offers it on its Scale plan. Eligibility and plan tier are the whole answer in both cases.

‍

If you were hoping to shortlist by certification instead, Google Cloud is blunt about it: there is no HIPAA certification recognized by HHS, and compliance is shared between customer and provider. Nobody can hand you a certificate that settles the question.

‍

Which leaves the builder. It's usually the one layer with no route into scope on any plan, which is why it gets replaced rather than hardened.

‍

What comes across, and what gets rebuilt

Migration sounds like rewrite. It usually isn't. When you migrate off Replit or Lovable, you keep everything that took judgment: the screens you argued over, the data model you got right on the third attempt, the rules your product runs on. What gets rebuilt is mostly plumbing.

‍

Settle one thing before you choose where to land. With Specode you retain rights to your data, content, code, and application, and you can export and continue elsewhere during your subscription and for 60 days after it ends. Ask your next platform that question now rather than after a second migration. That's what full code ownership has to mean in practice.

‍

Where the line falls

Run this against your own repository.

The line isn't drawn by difficulty. It's drawn by coupling. Everything in the right column was tied to the platform you're leaving, which is why it doesn't survive. That's the practical face of vendor lock-in: you can get your files out, and half of what's in them only runs in one place.

‍

A healthcare app migration therefore looks less like a rewrite than a re-hosting with an auth rebuild attached. The same shape shows up in turning a Replit prototype into a production app, where code export hands you the files and the platform-coupled parts still need doing.

‍

Why the plan comes before the work

A migration worth agreeing to is planned before it's built. Specode reads your codebase and produces a plan: what transfers, what has to change, and how the move would go. You see that plan and walk through it before any work starts.

‍

That gate is the thing to insist on with any vendor, not just this one. A plan you can read is a plan you can argue with, which is how you find out early that someone misread your data model. If nobody will show you one before they start, you aren't being offered a migration. You're being offered a rewrite with your logo on it.

The safeguards no vendor agreement covers for you

Signing the right agreements doesn't finish the job. It moves a boundary. Your hosting provider takes responsibility for its own infrastructure, and everything on your side of that line is still your build, written by you or by an AI that was never asked to think about it.

‍

That's the part teams underestimate, because none of it shows up in a demo. The app works. Nothing visibly fails. You find out when someone with a checklist goes looking.

‍

You can't fix all of it at once, so it helps to know which piece to start with.

What the rule already requires

Some of this is live today, not waiting on a future rulemaking. Under the HIPAA Security Rule as it stands, access control, audit controls, integrity, authentication, and transmission security are standards you have to meet. That means audit logging isn't optional hardening you can defer, and neither is role-based access control. Unique user identification is required outright, which is why shared logins fail on contact.

‍

Encryption at rest, encryption in transit, and automatic logoff are addressable, which gets widely misread as optional. It means you implement it, or you document why it isn't reasonable and appropriate for you and adopt an equivalent alternative where one is reasonable. Those are the technical safeguards as they stand today.

‍

Here's what that means for a prototype: it almost certainly has no audit trail at all. Nothing in the build ever needed one.

‍

Where prototypes actually leak

The failures in this class of app are boringly consistent. Go looking for these:

• Patient identifiers sitting in URLs and query strings, where they end up in browser history, referrer headers, and analytics.
• Debug statements writing electronic protected health information into application logs and error output, usually one nobody removed after a bad afternoon.
• Database access left wide open from development, because the demo needed every row visible and nobody narrowed it afterwards.
• Notifications and emails quoting clinical detail in the body or, worse, the subject line.
• Uploaded files served from URLs that are unguessable rather than authorized.

Encryption belongs on that list too, even though the current rule treats it as addressable, and the reason encryption at rest earns its place is worth understanding. The Department's position is that data encrypted to its guidance isn't unsecured protected health information, which puts it outside breach notification reporting. Encrypt, and a stolen laptop is an incident you handle. Don't, and it's a notification event you announce.

‍

Start with the logs. It's the cheapest thing to check, it's where AI-generated code leaks most reliably, and it's the same failure mode behind whether your prompts contain PHI.

‍

What the proposed Security Rule would change, and when

You'll read that encryption and multi-factor authentication became mandatory in 2026. They didn't. The January 2025 proposal to update the Security Rule is a notice of proposed rulemaking, its comment period closed that March, and none of it is in force.

‍

It isn't imminent either. According to the most recent regulatory agenda entry, the rule sits at the long-term actions stage with final action targeted for July 2027. The edition before that had it at final rule stage, targeted for May 2026. It has slipped once already, and an agenda date is a projection rather than a deadline.

As proposed, three things would change:

• Addressable disappears, so you meet the implementation specifications instead of documenting your way around them.
• Encryption becomes a requirement at rest and in transit, with narrow documented exceptions.
• Multi-factor authentication spreads across the systems that touch patient data, and to privilege changes.

None of which should change your plan. Those controls are already on the list from the last section, and a migration is the cheapest moment you will ever have to install them. You're rebuilding authentication anyway, so add the second factor. You're moving the data anyway, so encrypt it on the way.

‍

What the move looks like for four common builds

Four builds turn up again and again, and they don't hit the same wall. Where the binding constraint sits depends on the shape of the application, which is why the inventory is worth running rather than guessing. Two of them stall on storage. Two stall somewhere less obvious. What follows walks a telehealth consultation MVP, a patient intake tool, a provider portal, and a wellness product moving into clinical territory. There are more healthcare use cases than these four, but the pattern holds.

‍

When the data layer is what stops you

A telehealth consultation MVP is the common case. Video, scheduling, a notes field, and a Postgres database underneath, usually Supabase because that's what the builder wired up. The database isn't your problem. It can come into scope on its vendor's own conditions. What can't come is the builder sitting on top of it, so the work lands in three places:

• The builder layer, which gets replaced outright.
• The safeguards from the last section: audit trail, access control, clean logs.
• Patient identifiers in the URLs your video room hands around.

A patient intake tool looks nothing like that and lands in the same place. The data model is simple, the screens are mostly forms, and nearly all the risk sits in where answers get written and who can read them later. If yours is still collecting real answers, stop and prototype with synthetic patient data until the foundation is underneath it.

‍

When the constraint isn't where you expect

A provider portal or marketplace moves the constraint somewhere else entirely. Storage is the easy part. The hard part is that several classes of user now read overlapping slices of the same records, and the access rules a demo never needed become the main body of the work. Expect the work to concentrate on roles and row-level permissions rather than on infrastructure.

‍

The wellness product is the one that catches people out. Nothing in the code changes. You add a licensed clinician, or you start storing what they said back, and rows that were lifestyle data yesterday are patient records today. The obligation follows the data rather than the codebase, so a decision made in a roadmap meeting can move you into scope overnight, with no commit to point at. Which is the argument for running the inventory rather than assuming it: the constraint is rarely where you expected it.

‍

What moving to Specode actually involves

You've got the list. If you'd rather hand the project to someone who does this every week, here's the whole sequence, so you can judge what you'd be agreeing to before you agree to it. Specode is an AI-powered healthcare application builder: you describe what you need in plain English and define the UI, workflows, data model, permissions, and integrations. What follows is what a migration onto it looks like end to end, including the points where you have to make a call.

‍

First, read-only access to your repository

Nothing starts until you grant it, and granting it takes a couple of minutes. You pick the account that owns the repository, choose to grant access to selected repositories rather than all of them, and install. Nothing gets downloaded and nothing changes on your side.

‍

The access is read-only, and it's worth being precise about what that means. The app:

• Can read code in the repositories you selected, and see basic details like names and branches.
• Cannot change, delete, or push code.
• Cannot open pull requests or issues.
• Cannot see repositories you didn't select.
• Cannot see your password or account settings.

You remove it the same way you granted it, from your own GitHub application settings, without asking us.

‍

One precondition: the code has to be in a GitHub repository, or exportable to one. That covers Lovable, Bolt, v0 and Vercel, plus custom React or Next.js on hosting that isn't HIPAA-ready. If yours isn't in a repo yet, that's the first thing to sort out.

‍

Then the scan, and the project map it produces

The scan reads the code and builds a project map: your pages, your data models, how authentication works, and where data is actually stored. That last one surprises people, because prototypes accumulate storage nobody remembers adding, and a file bucket wired in for one demo counts the same as your main database.

‍

The map sorts everything you have into three buckets:

• What transfers directly.
• What needs adjustment to meet compliance requirements.
• What won't work in a HIPAA environment, flagged as such.

The third bucket is the one to read first. Those aren't engineering problems with an obvious fix, they're decisions you have to make: a vendor with no route into scope, an integration that can't be brought under an agreement, a feature that assumed data could go somewhere it can't. Better to meet them on a plan than halfway through the work with a date attached.

‍

You approve the plan before any work starts

We walk you through what the map found and how the move would work, and nothing starts until you've agreed to it. You should know what's changing and why before the work starts, including the items in the third bucket and what we propose doing about each one. If one of those answers is wrong for your product, this is the cheap moment to say so rather than the expensive one.

‍

That's also where the timeline stops being a guess. Simple to moderately complex applications commonly move in about a week, once our team has reviewed your codebase and confirmed that's realistic for yours. Before the review it's a range; after it, it's a plan.

‍

None of this begins with a form. Migrations start as a conversation, which is why the plan exists before the invoice does.

‍

The move itself, and what ships around it

The move lands your application on HIPAA-ready infrastructure using pre-built healthcare components rather than parts assembled from scratch. After it, you carry on with the AI coder the way you did on your old builder, except the foundation underneath is different.

‍

Three things come with that, and they map onto the gaps from earlier.

‍

The HIPAA Agent scans your code from the Compliance Center and reports findings across eleven categories, split into must-fix and recommended. You send any finding to the AI coder, it changes the code, and you re-run the scan to confirm it's resolved. Each scan is saved with a score, so you can see whether you're moving in the right direction.

‍

Before you go to production, someone here reviews the application for security and HIPAA readiness. That's a review before launch, not standing supervision of your codebase.

‍

And production runs on your own Convex account, set up as part of going live, which publishes a SOC 2 Type II attestation. HIPAA coverage there comes from signing Convex's standard agreement rather than negotiating your own. Third-party services you add on top may need their own agreements, and we'll tell you which ones apply to your setup.

‍

What you end up with is your application, on infrastructure that was built for patient data, still yours to change.

‍

Where to start

Migrations begin with a conversation, not a signup form. So book a demo and we'll go through your stack, tell you which bucket each part falls into, and say plainly whether a move makes sense for you. Sometimes the answer is not yet, and that's worth knowing before you spend a quarter on it.

‍

If you'd rather see your own gaps before talking to anyone, start with a HIPAA compliance scan. Either way you'll know what it takes to build a HIPAA-compliant healthcare app on what you already have.