Recovery for an AI-built app has two halves: getting the tool back to a version that worked (rollback) and getting the data back to a point before something went wrong (a backup restore). Before your team relies on any tool, know how much data you could lose, how long you could be down, who does the recovery, and whether you have ever actually tried it. Keep your own regular export of the most important records, and choose a platform that records every change so you always know what to roll back.
Every business tool eventually has a bad day. A change goes in that breaks the schedule screen. Someone bulk-deletes the wrong records. An import overwrites a month of job notes. With AI-built tools, the bad day can arrive faster, because changes are easy to make and an AI can take many actions in seconds. The question is not whether something will go wrong, but how quickly and completely you can get back.
This guide explains recovery in plain terms: what backups and rollback are, the two numbers every owner should know for each tool, the questions to put to any platform, a recovery plan you can fill in today, and a restore drill a non-developer can run. It is written for owners, IT leads and finance leads who need confidence that a tool the team depends on can be brought back.
Why recovery matters more with AI-built tools
AI changes the pace of software. A person describing a change in plain words can alter a tool in minutes, and an AI agent can act on many records at once. That speed is the benefit, and it is also why recovery planning matters.
The clearest example is public. On July 23, 2025, Fortune reported that an AI agent on Replit wiped SaaStr's live database, which held records on more than 1,200 executives and over 1,190 companies, during a code freeze. Replit promised separation between development and live databases and a planning-only mode in response. Our guide to the incident and how to prevent it covers it in detail.
Platforms can also change in ways that affect your data. Lovable says a February 2026 regression exposed public projects' chat history and source code from February 3 to April 20, 2026. That was an exposure rather than a loss, but it shows how a change on the platform side can reach your projects without you doing anything.
And AI output is often almost right. In the 2025 Stack Overflow Developer Survey, 66 percent of developers named "AI solutions that are almost right, but not quite" as their top frustration. A change that is almost right can quietly corrupt records for days before anyone notices, which makes the ability to go back to a known good point essential.
Plain definitions
- Backup: a saved copy of your data at a point in time, kept somewhere separate, that you can restore from.
- Restore: putting data back from a backup.
- Rollback: returning the tool itself, its screens and rules, to an earlier version that worked.
- Export: downloading your records in a common format, such as a spreadsheet file, that you keep yourself.
- Version history: a list of every change to a tool, so you can see what changed and return to an earlier version.
Two numbers every owner should know
Recovery specialists use two measures. You do not need their jargon, just the questions.
| Question | What it means | Example answer for a busy dispatch tool | Example answer for a rarely changed price list |
|---|---|---|---|
| How much could we lose? | The time between your most recent good backup and the problem. Everything entered in that window may need re-entering | No more than a few hours of jobs | A week of changes is fine |
| How long could we be down? | The time from discovering the problem to the tool working again | Under half a day, or the crew goes back to paper | A couple of days is fine |
Decide these for each important tool, then check that the platform's answers match. If the platform backs up daily but your team could not survive losing a day of orders, you need a more frequent export of your own or a different arrangement.
What can go wrong, and what fixes it
| What happened | Example | What recovers it |
|---|---|---|
| A bad change to the tool | A new rule hides finished jobs from the list | Roll the tool back to the previous version |
| Records deleted by mistake | Someone deletes a month of entries | Restore data from a backup |
| Records changed wrongly | An import overwrites customer phone numbers | Restore the affected records, or roll back plus restore |
| A tool stops working entirely | The tool will not open after a change | Roll back the tool, then check the data |
| Someone leaves with the only access | The tool lived in a former employee's personal account | Prevention only: tools must belong to the company |
| Data exposed rather than lost | Records were readable by outsiders | Restrict access first; recovery is about trust and notification, not restoring |
Notice the last two rows. Some problems cannot be fixed by restoring anything. A tool tied to a personal account is gone when its owner is gone, and exposed data cannot be un-exposed. Those are prevented by choosing the right platform, not by backups.
Questions to ask any platform
Bring this list to every vendor. Get the answers in writing.
- How often is our data backed up? Continuously, hourly, daily?
- How far back can we restore? Days, weeks, months?
- Who performs a restore, and how do we ask for one? Can we do it ourselves, or do we contact support?
- How long does a restore usually take?
- Can we restore a single tool, or only everything at once?
- Can we roll a tool back to an earlier version? How many versions are kept?
- Where are backups kept? Can the tools that build and change apps reach them?
- Can we export our data ourselves, in a common format, at any time?
- Is there a record of every change? Who asked for it, what changed, and when.
- What happens to our data if we leave the platform? How long do we have to take it with us?
A vendor that answers all ten plainly is taking recovery seriously. Our AI platform due diligence checklist puts these questions alongside the rest of what to check before you sign.
Keep your own copy
Whatever the platform promises, keep your own regular export of the records that would hurt most to lose. This is an old rule in IT, often summed up as keeping more than one copy, in more than one place, with at least one somewhere separate from the main system. For a small company, that can be as simple as:
- Pick the records that matter. Customers, open jobs, orders, invoices, inventory counts.
- Export them on a schedule. Weekly for most, daily for busy tools.
- Store them in a company account, not a personal one, with access limited to the owner and admin.
- Name files by date so you can find any point quickly.
- Open one export each month to confirm it actually contains what you expect.
A recovery plan you can fill in today
One page per important tool. Keep it with your app register.
- Tool name and business owner.
- How much we could lose: your answer from the table above.
- How long we could be down: your answer from the table above.
- Who notices: the person most likely to spot a problem first.
- Who acts: the admin who freezes changes and contacts the vendor.
- Who decides: the owner, for anything involving customer data or a long outage.
- Vendor contact: how to request a restore or rollback.
- Our own export: where it is and how recent.
- Fallback: what the team does while the tool is down, such as paper forms or the old spreadsheet.
Run a restore drill
A backup you have never restored is a hope. Run a drill once when a tool goes live and once a year after.
- Pick a safe target. A test copy of a tool or a set of test records.
- Write down the time and pretend the records were lost.
- Follow your recovery plan exactly as written, contacting the vendor if that is the process.
- Restore and check. Confirm the records are back and complete.
- Write down the time again. Compare to how long you said you could be down.
- Fix the plan. Update anything that was unclear, slow or wrong.
When it happens for real
- Freeze changes to the affected tool through permissions, not just a message to the team.
- Preserve the record of what happened. Do not delete or rebuild anything yet.
- Switch to the fallback so work continues.
- Find the last good point using the change record.
- Roll back, restore or both, depending on what went wrong.
- Fill the gap from your own export, email, paper or people's memory.
- Fix the cause before changes resume.
- Review the plan and update it with what you learned.
Common recovery mistakes
These are the mistakes that turn a bad afternoon into a bad month. Each one is easy to avoid if you know it in advance.
- Assuming the vendor backs up everything. Some platforms back up the tool but not the data, or back up the data only on higher plans. Ask, and get the answer in writing.
- Restoring before understanding. Restoring immediately can wipe out good work entered after the problem started. Use the change record to find the exact last good point first.
- Rebuilding from scratch with AI. When a tool breaks, it is tempting to describe it again and start over. A fresh build does not bring back the data, and it may not match the old tool's rules exactly.
- Keeping exports in a personal account. An export on someone's laptop or personal drive leaves when they do. Keep exports in a company account.
- Never opening the export. Files can be empty, cut off or missing columns. Open one every month.
- No fallback for the crew. If the dispatch tool is down for half a day, the team needs to know what to do in the meantime. A printed form in the truck is a fine fallback.
- Not telling anyone. When records are restored to an earlier point, everyone who entered work since then needs to know what to re-enter.
Recovery and the person who built the tool
One more recovery risk is easy to miss: the builder. If only one person knows how a tool works and where its data lives, the recovery plan depends on them being available. Make sure at least two people, usually the business owner and the admin, can find the tool, read its change record and contact the vendor. Our guide to who is responsible when employee-built software breaks covers ownership in detail.
How FORGE handles it
The best recovery is the one you never need. FORGE is built to stop bad changes before they reach your tools, and to make it obvious what changed if you ever need to look back.
- Checked before it is saved. A dedicated AI crew builds each tool, every piece is checked for quality and security before it is ever saved, and the tool is checked at every step. Almost-right output is caught before it lands.
- Planned before it is built. A panel of top AI models plans each tool before any building starts, so changes have a clear scope.
- A complete record. Every step of every build is recorded with who or what did it, from the first plan to the final touch. If something needs undoing, you know exactly what changed and when.
- Roles limit who can change tools. App users use the tools without being able to change them. Owners and admins decide who holds a builder seat.
- Tools belong to the company. Every app lives inside your company, and when someone leaves, removing them ends their access while every tool they built stays with you.
- Mistakes do not cost you. A build FORGE fails is free, and changes only count when something actually changes.
In your workflow workshop, our team walks your IT lead through exactly how FORGE handles your data, on your real work. Bring this guide's questions. Talk to us.
Questions people ask
What is the difference between a backup and a rollback?
A rollback returns the app itself, its screens and logic, to an earlier working version. A backup restore returns the data, your records, to an earlier point in time. A bad change to the app needs a rollback. Deleted or damaged records need a restore. Many incidents need both.
How often should AI-built app data be backed up?
Often enough that losing the time since the last backup would be acceptable. For a busy scheduling or orders tool that may mean continuously or at least daily. For a reference list that changes monthly, weekly may be fine. Decide per tool, based on how much re-entry your team could tolerate.
Can an AI agent delete our backups too?
It depends on how the platform is built. In the best documented case, an AI agent wiped a company's live database in July 2025. Backups should be kept where the tools that build and change apps cannot reach them, and you should also keep your own export.
What is a restore drill?
A restore drill is a practice recovery. You pick a non-critical tool or test data, pretend it was lost, and recover it, timing each step. It proves the backup works and that your team knows the steps before a real emergency.
Should we keep our own copy of our data?
Yes, for anything important. A regular export of key records to a place your company controls means you are never fully dependent on one vendor's recovery process.
What should we ask a platform about recovery?
How often data is backed up, how far back you can go, how long a restore takes, who performs it, whether you can roll back a tool to an earlier version, and how you export your data. Get the answers in writing.
How does FORGE help teams recover from mistakes?
FORGE prevents most mistakes before they reach a tool: every piece is checked for quality and security before it is saved, and the tool is checked at every step. Every step of every build is recorded with who or what did it, so you always know exactly what changed and when, and your IT lead gets a full walkthrough of how FORGE handles your data in the workflow workshop.
See what FORGE builds for your team
We onboard every team ourselves, starting with the work that costs you the most time.
Talk to us
