Broken website or AI app? Recovery guide

You open your website and see a blank page. Customers can sign in but cannot book. Or the app you built with AI works in preview and fails after publishing. Start by collecting enough information to choose the next step.

This guide is free to use. Download the repair brief (TXT) and fill in what you know. You can use it with your hosting provider, your developer or our website repair service.

1. Pause changes and record what happened

Pause new deployments and automated editing while you establish the current state. Save the exact error, affected URL, time and timezone, and the last time the feature worked. Record any recent publish, domain change, payment setting change or database update.

Try to describe a customer action: “I enter my email and the sign-in link never arrives” is more useful than “login is broken”. A screenshot can help, with customer details and secrets removed.

If a customer action could take money, send messages or change records, use a test environment or ask the provider to investigate. Repeated live attempts can create duplicate activity.

2. Check the services your site depends on

Look at your hosting, database, payment and email providers' official status pages. Examples include Vercel Status, Supabase Status and Stripe Status.

Record any incident that matches your service, region and timing. A provider outage can explain a failure without a code change. A green status page is only one piece of evidence; your account or project may still need support.

For a live outage, open a support request with the affected provider. Include the project identifier, error and timestamps through its private support channel.

3. Preserve what you have

Keep a copy of the current source code or repository, the last known working version, relevant logs and a list of available backups with their dates. Store these privately. Keep the original evidence as well as a redacted version for sharing.

Ask your provider or developer to preserve the database and uploaded files using the supported backup process. Confirm which environment each backup belongs to. A project export can contain code while customer records remain in a separate service.

If records appear to be missing, minimise further writes with your provider's help and establish which recovery points exist before restoring anything.

4. Separate code recovery from data recovery

A previous code version can restore how an app behaves. A database restore can replace the records it holds. Customer orders or registrations created after the chosen backup need an explicit preservation and reconciliation plan.

Recovery controls differ by platform and plan. Check the current documentation against your project:

• Lovable's troubleshooting guidance describes investigating errors and previewing earlier versions. Check the connected backend separately before deciding what to revert.
• Replit's checkpoint and rollback documentation explains its recovery controls. Confirm the checkpoint contents and the database environment involved before using them.
• Supabase's backup documentation explains available database recovery options. Its database backups do not contain the uploaded objects held in Storage, so files need their own recovery plan.

Where possible, validate a restore in a separate environment first. Keep that environment disconnected from live payments, customer email and other actions until its configuration has been checked.

5. Handle exposed data through the right support route

If users can see someone else's records, an account appears compromised or a privileged key is public, contact the affected provider's security support and your incident-response specialist promptly. Preserve logs and timestamps. Ask them to help restrict the affected access and revoke or rotate exposed credentials while retaining the evidence needed to investigate.

Use a secure channel for sensitive details. Public forums, AI prompts and enquiry forms should contain redacted descriptions rather than passwords, API keys or customer records.

6. Give a developer a useful repair brief

Include the details below. “Not sure” is useful where you do not know an answer.

Download the editable repair brief

. Keep a copy so you have one record of the incident and each attempted fix.

7. Agree what a successful repair looks like

Before repair work starts, agree the affected features, price, release plan and acceptance checks. For a booking flow, that might mean the appointment is saved, the correct availability changes and the confirmation arrives. For checkout, it includes the payment result and the matching order record.

After the repair, ask for a record of the change and the checks completed. Backup coverage, monitoring and a tested restore procedure can then become a separate follow-up scope.

Get help with the next step

For an existing live site, request a website repair review. For a project you built with AI, read how AI app rescue works or send your project details.

We review technical fit and availability first. Any paid diagnosis is agreed before investigation; the findings then support a separate repair or launch quote.

website repair · AI app rescue · recovery