The loop every AI builder founder knows
Something small is wrong. You describe it to your builder, it changes some code confidently, the fix works, and somewhere nearby something else quietly stops working. Checkout, usually. Or the login you fixed last week. You prompt again, and the repair knocks a third thing sideways. After a few rounds you are not maintaining an app anymore. You are negotiating with it, and you start avoiding changes the business needs because every change feels like a coin toss on the live product.
Why it keeps happening
The builder works on what it can see, and what it can see is the code, not the history of why the code is that way. That odd conditional near the checkout is often a scar from a real bug, but it looks like clutter to a fresh read, so it gets tidied away and the bug comes home. Production makes this expensive in specific ways. If your app is not connected to version control, or the connection quietly lapsed, there is no clean yesterday to return to. If changes deploy straight to production, your customers are the test environment. And database changes are the sharpest version: a migration that renames, drops, or retypes something can lock every user out of their own data in one step, and unlike code, data does not redeploy.
Underneath all of it sits the backup question. A backup that has never been restored is not a recovery plan. It is a file you hope is good, and the moment you would test that hope is the moment you can least afford a surprise.
A calmer workflow, in the order that matters
First, connect version control properly and confirm it is recording every change, because the ability to return to yesterday is the whole game. Second, never let the builder work directly on the live deployment: use preview or staging builds, click the actual flow the change touches, and only then promote it. Third, one change at a time, described narrowly. Fix the reset link is a task. Improve the account area is an invitation to rewrite six things and break two. Fourth, treat database changes as their own category: read what will change before it runs, and never let a change drop or rename anything holding customer data without a backup from the same day sitting beside it. Fifth, test a restore before you need one. Restore the latest backup into a throwaway copy, count the rows, log in, and write down how long it took. That twenty minute exercise is the difference between an incident and a disaster.
This is deliberately not a set of prompts. The failures above come from process, not phrasing, and a better prompt aimed at the same straight to production workflow produces the same coin toss with nicer wording.
Verify it: you can point at the exact previous version of your app and return to it in minutes, your last change was reviewed on a preview before a customer saw it, and your latest backup has a restore date and a duration written down next to it.
FAQ
The builder says the change is small and safe. Should I still preview it?
Yes, because small and safe describes the intention, not the blast radius. The preview is where you discover that the change touched the login page on its way through, and discovering it there costs nothing.
I do not have version control connected. Is it too late?
No, and it is the highest value hour you can spend on the app this week. Connect it now, let the current working state become the first recorded version, and every fix after that has a way back.
How often should a backup restore be tested?
Monthly is a sane rhythm for a live app, and again after any big database change. The answer you want written down is always recent: it worked, on this date, in about this long.
Ground Crew note
On the Ground Crew plan, the restore test is not advice, it is a monthly deliverable, and fixes ship as small reviewed changes rather than straight to production edits. If your app already feels fragile, start with the free audit: the post launch checklist is public, and the audit itself runs the recovery checks against your live app.