Picture this. You wake up, check your phone, and your app is down. Not because you changed anything, but because the platform it lives on is having a bad day. Or your database is frozen behind a billing glitch you didn't cause. Or you try to download your own code and the export button just spins. Suddenly your entire business is hostage to one company's servers, and you have no way out.

I see this almost every week. A founder builds their whole product inside a single AI tool, ships it, and gets real users. Then the thing that keeps them up at night isn't a bug in their code. It's the growing realization that they don't actually control where their app lives. This is Replit vendor lock-in, and it applies to Lovable, Bolt, and every other all-in-one builder too.

In this post I'll explain in plain English what you actually own, what you don't, and how to get your code and data somewhere safe so a single outage or billing hiccup can never take your business offline for days. You don't need to understand the code to do most of this. You just need to know where the doors are.

What "vendor lock-in" actually means

Vendor lock-in is a fancy phrase for a simple, uncomfortable situation: your app depends so heavily on one platform that leaving it (or even surviving a bad day on it) becomes painful or impossible.

With AI builders, lock-in usually shows up in three layers stacked on top of each other:

  • Your code lives there. The files the AI generated sit inside the platform's editor. If you can't easily pull them out, you don't really have a copy.
  • Your database lives there. Your users, their data, your content, all of it is stored on infrastructure the platform manages. If they freeze it, you can't reach your own data.
  • Your hosting lives there. The public URL your users visit is served by that one platform. When it goes down, you go down, and there's no backup location to switch to.

Here's the thing. Each layer alone is manageable. The danger is when all three sit inside a single account you don't fully control. A billing error, an outage, or a policy change can knock out your whole business at once, and you have no independent copy to fall back on.

Owning your app means having your code, your data, and a way to host it that survives any single company having a bad day.

Why AI builders create this trap

I want to be fair to these tools. Replit, Lovable, and the rest are genuinely great at one thing: getting an idea from "in my head" to "live on the internet" in an afternoon. The reason they can do that is the same reason they create lock-in.

To make building feel effortless, they bundle everything together. The editor, the database, the hosting, the deployment, the environment settings, all wrapped in one friendly interface. You never have to think about where anything lives, because the platform handles it. That's the magic.

But convenience and control are opposites here. Every piece the platform manages for you is a piece you don't hold a copy of. The AI optimizes for "this works in the demo," not "this founder can walk away with their business intact." Portability is unglamorous, so it gets skipped. (I've written more about that pattern in the hidden cost of vibe-coding debt.)

And because the whole point is that you never look under the hood, most founders don't discover the lock-in until the day they urgently need out. That's the worst possible day to learn where your data is stored.

What it looks like when lock-in bites

Let me get concrete, because these symptoms are the ones that actually send founders looking for the exit.

The platform has an outage and you're just stuck

The provider's servers go down, and so does your app. You refresh their status page while your users email you. You have no second location to point traffic at, so all you can do is wait and hope. An outage that lasts hours for them can feel like a catastrophe for you.

A billing glitch freezes your database

This one is brutal. A payment fails, a card expires, or the platform's billing system hiccups, and your database gets locked or suspended. Your app can't read its own data. Your users see errors on the core thing your product does. And you're stuck in a support queue while your business sits frozen.

The export button doesn't really export everything

Some platforms let you download your code but not your database. Some give you the code in a state that won't run anywhere else without significant rework. You think you have a copy, but what you actually have is a pile of files missing the pieces that make them work.

You can't answer basic questions about your own app

Where is my database hosted? Where are my secret keys stored? How would I move this if I had to? If those questions make your stomach drop, that's the lock-in talking. Not knowing is itself the risk.

If you've hit any of these, you're not doing anything wrong. This is the normal next chapter after a fast launch. The good news is it's fixable, and most of the fix is about getting copies into your own hands.

What you actually own (and what you're renting)

Before you move anything, get clear on the difference between what's yours and what belongs to the platform.

Yours, or should be:

  • Your source code. The files that describe your app. You have a right to these, and you should hold a copy outside the platform.
  • Your data. Your users and everything they've created. This is your business. You need to be able to export it in a standard format.
  • Your domain name. If you bought your domain through the platform, consider moving it to an independent registrar so you control where it points.

The platform's, and fine to rent:

  • The convenient editor and AI assistant.
  • The managed infrastructure that runs things for you.
  • The specific way they wire services together.

The goal isn't to abandon the platform. Renting hosting is completely normal and often the right choice. The goal is to never be in a position where losing that rental means losing your code and your data too. You keep renting the convenience. You stop renting the things that are fundamentally yours.

How to get your app out of the trap

Here's the practical part. You can do a lot of this yourself in an afternoon. I'll be honest about where a real developer saves you from a painful mistake.

Step 1: Get your code into your own GitHub account

GitHub is the standard place developers store code. It gives you a full history and a copy that lives independently of any builder. Most AI platforms can connect to GitHub directly, and many already have.

  1. Create a free GitHub account if you don't have one.
  2. In your platform's settings, look for a "connect to GitHub" or "export to repository" option and use it.
  3. Confirm the code actually landed there by browsing the files in GitHub.

Once your code is in GitHub, you own a real copy. Even if the platform vanished tomorrow, your code wouldn't.

Step 2: Export your database and set up real backups

Your code is only half the picture. Your data is the half that's irreplaceable. Losing code means rebuilding features. Losing data means losing your customers' trust and possibly your business.

Find your platform's database export option and download a copy in a standard format (usually a .sql file or .csv files). Store it somewhere safe that isn't the platform itself. Then set up automatic recurring backups so you're never relying on a single manual download.

This is so important that I wrote a whole piece on what happens when an AI-built app has no backups. If you read one linked article, make it that one.

# A developer will often move your data to an independent
# database host, then keep a scheduled dump like this:
pg_dump "$DATABASE_URL" > backup-$(date +%F).sql

You don't need to run that yourself. I show it so you can see how ordinary this is once your data lives somewhere you control.

Step 3: Find and secure your keys and secrets

Your app talks to other services (payments, email, login) using secret keys. On an all-in-one platform, those secrets are stored in the platform's settings. If you ever move, you need to know what they are and where they go.

Make a simple list: every external service, what it does, and where its key is stored. This is boring and it will save you on your worst day. While you're at it, this is a good moment to check that those keys aren't accidentally exposed in your code, which AI builders do more often than you'd think. I go deeper on that in why your AI-built auth is probably broken.

Step 4: Understand your path to portable hosting

Portable hosting just means your app can run somewhere other than the builder it was born in. Once your code is in GitHub and your data is exportable, you have options. Hosts like Vercel, Netlify, Render, and Railway can run apps directly from a GitHub repository, and independent database providers can hold your data separately from your hosting.

You do not have to move today. The point is to know you can. A founder who can redeploy their app somewhere new in a day is never truly held hostage by one platform's outage.

Here's my honest note: actually performing the move, wiring the app to a new database, reconnecting the keys, and making sure nothing breaks in the process, is the step where founders get stuck. AI-built apps often tangle the platform's specific setup into the code, so a clean lift-and-shift rarely just works on the first try. This is exactly the kind of job I get called in for, because doing it wrong can mean downtime or lost data, and neither is a place to learn on the job.

Step 5: Reduce your dependence, don't panic

You don't have to do everything at once. Priorities, in order:

  1. Code in GitHub. Do this today. It's low-risk and high-value.
  2. A recent data export saved off-platform. Do this today too.
  3. A written list of your services and keys.
  4. Automatic backups running on a schedule.
  5. A tested plan to redeploy elsewhere if you ever need to.

The first three you can knock out in an afternoon. The last two are where having someone who does this for a living pays for itself.

You can keep the convenience without the cage

I want to be clear about the takeaway, because it's easy to read all this and feel like you have to rip your app off Replit right now. You don't. These builders are good tools, and staying on one is a perfectly valid choice.

What's not okay is being trapped. The difference between "I choose to host here" and "I'm stuck here" comes down to a few copies in your own hands: your code in GitHub, your data exported and backed up, and a clear-eyed understanding of what it would take to move if you had to. Get those in place and a single outage or billing bug becomes a bad afternoon instead of an existential threat.

If you've built something on Replit, Lovable, or Bolt and that hostage feeling is nagging at you, that uncertainty is the real problem, and it's very fixable. I review AI-built apps every week, get founders a safe copy of their code and data, and set up portable hosting so no single platform can take them offline for days. If you'd sleep better knowing you actually own your app, let's talk about what it would take to get you there.

Cover photo by panumas nikhomkhai on Pexels.