For apps with customer data · Supabase · Postgres
You have backups. Has anyone ever restored one?
You built something people use, and their data lives in your database. A backup that has never been restored is a file you hope works. Whether it does, and how long getting it back takes, is something you find out once: on the day you need it.
1 · How it happens
A backup exists. A restore has never happened.
On Supabase, daily database backups come with the paid plans; the free plan has no automatic ones. Either way, a backup existing and your app coming back from it are different questions. Getting an app back involves more than the file: the schema your code expects, the files in Storage (Supabase's database backups do not include them), and every setting that points at the database. Taking a backup tests none of that.
2 · What it costs
The worst day is the first rehearsal.
If your coding agent can reach the production database, one wrong tool call is enough: a migration run against the wrong database, a
DROP TABLEthat reports success, an update with noWHERE. If no restore has ever been run, that is the day anyone learns how long it takes, what the newest backup holds, and which of the day's orders, sign-ups and invoices are not in it. Your customers wait through all of it.3 · Why you haven't seen it
An untested backup looks exactly like a working one.
The dashboard lists backups, so the box feels ticked. Nothing fails until a restore is attempted, and on a small team nobody has had a reason to attempt one. “Last restore: never” is not written anywhere, which is why nobody worries about it.
What the free check shows you
The check reads your repository: backup scripts, schedules, runbooks, migrations, and where each environment's database connection comes from. It cannot see your hosting dashboard, so it cannot tell whether a restore was ever run. When nothing in the repository shows one, the report says so.
prodready · free checkNo database restore has ever been performed or written down.
The day a restore is needed is the day anyone learns how long it takes and whether yesterday's invoices are in it.
ChecklistINFRA-08EvidenceREADME.md:1
Uploaded files live in Storage buckets that no backup in the repository mentions; only the database is covered by the hosting plan's backups.
A restore brings the rows back and leaves every avatar, invoice PDF and attachment they point to missing.
ChecklistINFRA-08Evidencesupabase/config.toml:1
The development environment file points at the production database; the repository defines no separate development database.
Every migration and every query run during development, by you or by your coding agent, runs against your customers' data.
ChecklistINFRA-04Evidence.env.example:3
Run the free check tonight.
It runs in your coding tool, on your machine, in a few minutes. What reaches us: counts, rule names and file paths with line numbers. Never your source, your data or a secret value. Your report page is kept 7 days behind an access code. Exactly what it runs →
Add it, sign in, ask.
claude mcp add --transport http prodready https://mcp.prodready.si/mcp --scope user- Add it. Run it in a terminal.
- Sign in. In Claude Code type
/mcp, pick prodready, choose Authenticate. A browser page asks for your email; type the 6-digit code we send (or click its link), then approve. No password, no card. - Ask. Type “check my app”.
Send it to your laptop.
Built in Lovable, Replit or Base44, with no coding tool on your laptop? Connect the project to GitHub, open that folder in Claude Code or Cursor, then add the line above. The step-by-step guide →
After the report: when you want the gaps closed the way serious software teams close them, the same prodready connection runs the SDLC on your project. How that works →