What happens if my AI app platform suspends my account? Can I lose my app and my customers' data?

Everything written about getting your app off a platform — including things I have written — quietly assumes one thing: that you are the one deciding to leave. You log in, you press export, you download a file, you go.

This article is about the other case. The account is suspended. The app is offline. The export button is on the other side of a login that no longer works. And the thing standing between you and your customers' data is not a technical problem with a technical solution — it is a decision made by an automated system belonging to a company you cannot reach.

It is uncommon. It is not rare enough to ignore. And the preparation that makes it survivable takes about an afternoon.

What actually happened to people

In July 2026 somebody described losing access to their project completely — front end, back end, everything. The detail that made the account circulate widely, and it drew several hundred responses, was this: twelve gigabytes of their data was sitting on the platform's managed database, and because that database was managed, they had no credentials for it. No connection string, no dashboard, no second path. The data was intact and entirely out of reach.

They tried the appeal form. They tried messaging the company's founders directly. They posted publicly. The only thing that responded was a support bot.

Their source code survived, because they had connected a repository they owned. The database did not.

It was not an isolated shape. In the same window, users of another platform reported accounts blocked with custom domains still held by the platform. A user of a third reported their managed database project removed. Another had a site taken down following a copyright complaint. Different companies, different triggers, the same structure underneath.

Why this happens, and it is not malice

It helps to understand the mechanism, because it explains why appealing is so unsatisfying.

Platforms hosting hundreds of thousands of user-generated applications have to police them, and at that scale policing means automation. Automated systems produce false positives. That is not a flaw in a particular company; it is arithmetic. A system that never wrongly flags anybody is a system that catches nothing.

What makes it severe for this specific category of app is not the flagging. It is that the flagged account owns both the application and the only credentialed route to its database. In a conventional setup those are two separate relationships with two separate companies, and an action against one leaves the other untouched. On a builder-managed backend they are one relationship, so one action takes both.

And the appeal path is a form, because at that scale it has to be. The people describing these experiences were not being ignored by a person. They were being processed by a queue.

The asymmetry nobody points out

Here is the part I most want you to take away.

Connecting your project to a repository you own is presented as the safety step, it is easy, and nearly everyone does it. It protects your source code.

Source code is the most reproducible and least valuable asset in your entire system. If you lost every line tomorrow, an AI assistant would rebuild a working version of most small applications in a weekend, because that is precisely what these tools are good at. Annoying, expensive in time, survivable.

Your customers' records are not reproducible by anything. There is no tool that regenerates who signed up, what they bought, what they wrote, what they uploaded. That is the original. Everything else is a copy.

So the safety step everybody takes protects the copy, and the original is usually the thing with no second door.

What "you own your data" actually means

The phrase gets used loosely. Break it into three questions and it gets useful immediately.

Can you read your data right now without going through the platform's interface? If the answer requires logging into the builder, you do not have access — you have permission, and permission can be withdrawn.

Do you hold a copy that is not on their infrastructure? A file, on a machine or a storage account of yours. Not a backup they take on your behalf, which lives in the same place as the thing it is backing up.

Could you stand the app up somewhere else this week? Not perfectly, not in production — just running, with the real data in it. If you cannot answer yes, then whatever you hold is an archive rather than a recovery.

Most AI-built apps answer no to all three. That is not a failure of diligence, it is a consequence of the default configuration, and nobody was told that the default had this property.

The four levels of custody

Level one: nothing. Application, database, storage, authentication, domain and email all inside one account with one platform. This is where most AI-built apps sit today. A single account action removes all of it at once.

Level two: code in a repository you own. Necessary, cheap, and covers the least valuable thing. Do it, but do not mistake it for the answer.

Level three: an export you have actually downloaded. This is the big jump, and it is available to almost everybody today for the cost of an hour. It is not perfect — an export is a snapshot, and by the time you need it it is as stale as the day you took it — but the difference between a stale copy and no copy is the difference between a bad month and a closed business.

Level four: the database under your own account and your own billing. This is the only level that genuinely survives an action against the builder platform, and it is the reason people migrate. It is more work and it is not free. It is also the point at which the question stops being interesting, because your data is simply yours.

Level three is what I would push almost everybody towards this week. Level four is what I would push anybody with paying customers towards this quarter.

The drill, concretely

Call it leaving the building. It takes an hour the first time and about ten minutes thereafter.

Take the export. On Lovable this is in the project's advanced settings, capped at five gigabytes and limited to one per twenty-four hours.

Download it, and open it. Actually open the file. An export you have never opened is a hypothesis, not a backup. I have watched somebody discover during an emergency that their reassuring nightly export had been zero bytes for five weeks.

Store it somewhere unrelated to the platform and unrelated to the account you use for the platform.

Then collect the three things the export does not contain, because this is where people are caught out. Your stored files — anything uploaded by users lives in storage buckets and is not in a database dump. Your function code — server-side functions are not in the dump either, so copy them into your repository. Your secrets — API keys and configuration values, which typically cannot be read back out of the interface once entered, meaning that if the only copy of a key is in that settings page, the key effectively exists nowhere else.

And the fourth thing, which is not a file: your domain. If the domain is registered or managed through the platform, it is part of the account. Move it to a registrar of your own. That one is cheap, permanent, and it means that whatever else happens, the address your customers know still points wherever you say.

Put the whole thing in the calendar monthly. A drill you do once is a story you tell. A drill you do monthly is a capability.

Reducing the odds

You cannot make this impossible, and I am not going to pretend a checklist prevents an automated system from making a mistake. But some things measurably raise the chance that a review resolves in your favour.

Make the account look like a business, because a review is partly a judgement about whether an account is a real operating concern. Real business details, a payment method on file, a paid plan rather than a free one, a custom domain.

Do not share accounts. An account used by several people is harder to defend and easier to flag.

Read the acceptable use policy once if your product is anywhere near a sensitive category — scraping, messaging at volume, anything financial, anything adult-adjacent, anything involving other people's content. Not because the rules are unreasonable, but because "I did not know" carries no weight with a queue.

And respond to warning emails. In more than one of these accounts, there had been earlier notices to an address nobody was reading.

The honest limit

You cannot guarantee this never happens to you. Anybody who tells you otherwise is selling something.

What you can do is decide, in advance and calmly, that if it does happen it costs you a difficult fortnight rather than everything. The whole difference between those two outcomes is a downloaded file, a repository, a domain in your own name, and knowing where your secrets are written down.

That is genuinely an afternoon. It is the cheapest insurance in this entire subject, and the reason people skip it is not cost or difficulty — it is that nothing bad has happened yet, which is also the only moment at which it is possible to do.

If you would rather have somebody set this up properly

If you have read this and realised you do not actually know what you hold, that is the normal position and it is a bounded piece of work to fix.

I do a Production-Ready Audit that includes exactly this: every service the app depends on identified with whose account it sits under, an export taken and verified by opening it rather than by trusting it, storage and functions and secrets collected separately, the domain checked, and a written custody plan you keep afterwards. From $499, back in five to seven days.

You are also welcome to just tell me which platform you are on and what you think you have a copy of. I will tell you what is usually missing from that list, at no charge and with nothing attached.

The setup and migration work is described on the launch and deployment page. For the voluntary version of this question — what an export actually gives you across each platform — there is what you actually own when you export. The step-by-step of moving your database somewhere you control is in moving from Lovable Cloud to your own Supabase. And the more mundane way to end up locked out of your own backend, which happens far more often than a suspension, is in your Lovable app went down because you ran out of credits.