Security gets the attention, but the thing most likely to actually end a small app isn’t an attacker — it’s data loss. A dropped table, a migration run against the wrong database, a “cleanup” script that cleans up too much. Vibe-coded apps are especially exposed here because the safety nets are invisible until the day you reach for one and it isn’t there.
The three ways data dies
- No backups. The database has never been backed up, or “it’s backed up” means a setting nobody has tested. The first time anyone tries to restore is the first time anyone finds out it doesn’t work.
- Dev pointed at prod. Development and production share a database, or the same credentials. A seed script, a test that wipes tables, a stray
deletewhile building — and it lands on real users’ data. - Destructive migrations, run by hand. A schema change that drops or rewrites a column, applied directly to production with no review and no copy to fall back to. One typo is irreversible.
Why it happens
Backups and environment separation produce nothing visible. The app works exactly the same whether or not a backup exists, whether or not dev and prod are the same database. So in a fast build they’re the corner that gets cut — and the cut is silent until the worst possible moment.
The minimum before real data goes in
- Automated backups and a tested restore. A backup you’ve never restored is a hope, not a backup. Run a restore once, on purpose, and confirm you get your data back.
- Separate prod and dev. Different databases, different credentials. No development command should be able to touch production.
- Treat migrations as dangerous. Review them, prefer reversible ones, and run them against a copy or a staging database before production. Avoid
drop/destructive changes on a live table without a backup taken first. - Soft-delete user-facing deletes. A “delete” that flags a row is recoverable; one that removes it isn’t.
How to check
Three honest questions: Do you have a backup of your production data from today? Have you ever actually restored one? Could a command you run while developing reach production data? If the answers are “no,” “no,” and “yes,” you’re one ordinary mistake from a very bad day.
Data durability is the quiet half of a pre-launch read — not how someone breaks in, but whether one wrong command can wipe you out. A seniorgrade audit covers environment separation, backups and migration safety alongside the security review. The free self-check asks the backup question too.