Let me tell you about the worst phone call a founder can make. It usually starts with a long pause, then something like: "I ran a change the AI suggested, and now all my user data is gone. Can you get it back?"

Sometimes I can. Often I can't. And the difference almost always comes down to one thing nobody set up before launch: database backups for AI-built apps. If you built your app with Cursor, Lovable, Replit, or Bolt and you have never once thought about backups, this post is for you. I see this gap almost every week, and it is the single scariest one because it is the only mistake that can be truly permanent.

Here is what I want to give you. By the end of this, you will know how to check whether your app actually has real backups, how to tell the difference between a backup and a false sense of security, and how to get automated backups in place before you ever need them. No code experience required.

What "no backups" actually means

Your app's database is where everything important lives: your users, their accounts, their content, their orders, their messages. Everything. When people sign up and use your product, that data is the product. Lose it and you do not have a damaged app, you have an empty one.

A backup is a saved copy of that database, taken at a point in time, stored somewhere safe and separate. If something destroys the live data, you restore from the backup and you are back to where you were. No backup means there is no copy. When the data is gone, it is gone the way a deleted text message is gone.

Here is the part that catches founders off guard. Most assume that because their data lives "in the cloud," it is automatically safe. The cloud does not mean backed up. It means someone else runs the server. If you delete a row, or a bad change wipes a table, the cloud cheerfully stores the new empty version. It does exactly what it was told.

The cloud is not a backup. It will save your mistake just as faithfully as it saved your data.

Why AI-built apps end up with no backups

This is not because you did anything wrong. It is baked into how these tools work, and once you see why, you will never assume you are covered again.

AI builders optimize for one thing: getting a working app in front of you fast. Backups are invisible. They do not show up in the demo. They do not make a button appear or a page load. A backup only matters on the worst day, which is a day the AI is not thinking about because it is focused on making today work.

So the tool spins up a database, connects it to your app, and moves on. It almost never says, "By the way, you should turn on automated backups and confirm you can restore from them." That sentence does not help the demo, so it does not get spoken.

There is a second, sharper reason that is specific to AI-built apps. The same AI that built your app will happily suggest changes to your database later. And database changes (often called migrations, which just means a structured change to how your data is stored) are exactly where catastrophic deletes happen. A migration can drop a table, rename a column the wrong way, or wipe records as a side effect. The AI writes it confidently. It runs. And if there is no backup, there is no undo.

I have written before about how using more AI to fix AI-built code is like asking it to grade its own homework. Backups are the clearest example of why that matters. The tool that created the risk is not going to warn you about it.

The three ways founders lose everything

When I see permanent data loss, it almost always comes from one of these. None of them are exotic. All of them are preventable.

1. The bad migration

You ask the AI to add a feature or change how something is stored. It generates a database change. It runs cleanly, no error message, and quietly drops or overwrites real data in the process. The app still loads, so you do not notice for days. By then the original is long gone.

2. The accidental delete

You are poking around in your database admin panel, or you ask the AI to "clean up test data," and a delete runs wider than intended. One missing condition in a delete command is the difference between removing ten test rows and removing every row in the table.

3. The provider problem

Less common, but real. Your database host has an outage, an account billing issue suspends your service, or you accidentally delete the wrong project. If your only copy lived there, you are at the mercy of one company's support queue, and some of these situations are genuinely unrecoverable.

The common thread is that all three are silent and fast. There is no warning popup that says "you are about to lose everything." That is exactly why you have to set up the safety net in advance, while everything is calm.

How to check if your AI-built app actually has backups

You do not need to read code to do this. You need to log into the service that hosts your database and look. First, figure out where your data lives. Common ones for AI-built apps include Supabase, Neon, PlanetScale, Railway, Render, and plain Postgres or MySQL hosted somewhere. If you are not sure, the AI tool's dashboard or your project settings usually name it.

Once you know your host, work through this checklist:

  1. Find the backups or recovery section. Almost every database host has one. Log in, open your project, and look for a tab called "Backups," "Recovery," "Point-in-time recovery," or "Snapshots."
  2. Confirm backups are actually turned on. Some plans include automatic backups; many free tiers do not, or they keep them for a very short window. Read the actual setting, do not assume.
  3. Check how often they run and how long they are kept. A backup from 30 days ago is very different from one taken every day. Look for the frequency (daily is a reasonable minimum) and the retention (how many days of history you can roll back to).
  4. Find out if you can restore yourself. A backup you cannot restore from is a museum piece. See whether there is a "Restore" button you could actually click, or whether it requires contacting support.

If you go looking and find nothing, no backups tab, no schedule, no retention setting, then you have your answer. Your data has no copy, and you are one bad command away from starting over. That is not a reason to panic. It is a reason to spend the next hour fixing it.

A backup you have never tested is not a backup

This is the part even experienced people get wrong, so I want to say it plainly. The only backup that counts is one you have proven you can restore from. I have seen setups where backups were "running" for months, and when the bad day came, the restore failed because the backups were empty, corrupted, or pointed at the wrong database.

Think of it like a smoke alarm. Having one on the ceiling means nothing if the battery is dead. You test it on purpose, when there is no fire, so you trust it when there is.

So once you confirm backups exist, do a dry run. Restore a backup into a separate test database (not your live one) and look at the data. Does it have your users? Your content? Is it recent? If you can answer yes, you genuinely have a safety net. If you cannot, you have a checkbox, not protection.

How to add automated backups before disaster strikes

Here is the practical playbook. Most of this you can do yourself in an afternoon.

Step 1: Turn on your host's automated backups

This is the highest-value thing you can do, and it is often a single setting. Go into your database host and enable daily automated backups with the longest retention your plan allows. If you are on a free tier with no backups, this is the moment upgrading to a paid plan earns its keep. A few dollars a month against losing your entire business is not a hard call.

If your host offers point-in-time recovery, turn it on. That feature lets you restore to a specific moment, like "yesterday at 2pm, right before that change," instead of only to a once-a-day snapshot. It is the difference between losing a day of data and losing a few seconds.

Step 2: Add your own independent backup

Host backups are great, but they live with the host. If the problem is the host itself (a deleted project, a billing lockout), you want a copy somewhere else entirely. A simple scheduled export of your database to a separate storage location covers this. For Postgres, that is a regular pg_dump saved to cloud storage you control.

# A daily dump of your database to a file you control
pg_dump "$DATABASE_URL" > backup-$(date +%F).sql

You do not have to run that by hand every day. It can be set up to run automatically on a schedule. The point is having one copy that does not depend on a single company staying happy.

Step 3: Protect yourself before every database change

Backups protect you from yesterday's data. But the most dangerous moment is the instant you run a change. Before you ever let the AI run a migration or you edit data directly, take a fresh backup right then. A manual snapshot takes seconds and means that if the change goes sideways, you lose nothing.

Build this into a habit: no database change without a fresh backup first. This single rule prevents the most common catastrophe I get called about.

Step 4: Write down where everything lives

Keep a short note of which host has your database, where your independent backups go, and the exact steps to restore. On a bad day, panic makes simple things hard. A boring document you wrote calmly will save you. This is the same instinct that keeps the rest of an app maintainable, something I dig into more in the hidden cost of vibe-coding debt.

Step 5: Test the restore (yes, really)

Schedule a restore test. Once a month, or at least once after you set everything up, restore a backup into a throwaff database and confirm the data is all there and recent. This is the step almost everyone skips, and it is the one that turns a backup from a hope into a guarantee.

Where I draw the line for you

A lot of this you can and should handle yourself. Turning on host backups, watching that they run, taking a snapshot before changes, keeping that note current. That is founder-level work and it is genuinely the most important safety net you will ever add.

Where it gets riskier is restores under pressure, independent backup automation, and database changes that touch real user data. Restoring a live database the wrong way can make a bad situation worse, sometimes overwriting the good data you were trying to save. That is not a place to learn on the job at 11pm while users are emailing you. It is exactly the kind of high-stakes work I get called in for, because the cost of getting it wrong is everything.

If you have built an app with AI and you genuinely do not know whether your data is backed up, that uncertainty is the real problem, and it is fixable today. I review AI-built apps every week, confirm whether the backups are real, set up automated backups and a restore plan that actually works, and make sure a single bad change can never wipe you out. If you want to stop hoping your data is safe and actually know it is, let's take a look at what your app needs.

Cover photo by panumas nikhomkhai on Pexels.