How to rescue an app started with Lovable, Bolt, v0 or Replit
A practical diagnosis to understand what can be completed, where the real problems are and when a focused rebuild is safer.
A practical guide to diagnosing and rescuing an app started with Lovable, Bolt, v0 or Replit, covering code, login, data, security and deployment.
Step-by-step procedure
Use this guide as a diagnosis, not as a technology list. Start with the action the user is trying to complete, record where the flow stops and collect one piece of evidence for each check. If you cannot answer a point, mark it as missing information: that is already a useful result.
- 01
Reproduce the blocker
Create an ordinary test account and repeat the flow from the beginning. Record the page, action, expected result and actual result before changing any code.
- 02
Build the inventory
Collect source code, setup instructions, domain, hosting, database and connected services. Record who controls each account without copying credentials into the diagnosis.
- 03
Check one boundary at a time
Review build, login, permissions, data, secrets, payments and release in that order. Keep one simple piece of evidence for each area.
- 04
Choose the rescue path
Separate what works, what needs repair and what needs rebuilding. Only then define priorities, scope and estimate.
Never send passwords, tokens, .env files or private API keys through public forms, chats or screenshots.
Map the project before fixing it
Recover the source code and identify who owns hosting, the database, the domain and every connected service. Separate visual demos from functions that actually handle users and persistent data.
What to check
- Confirm the repository installs from a clean checkout.
- List providers and accounts without sharing credentials.
- Define one concrete outcome for the end user.
Check the production blockers
Build, authentication, permissions, persistent data, secrets, payments and deployment must be reviewed together. The first visible error is often only a symptom.
What to check
- The server must verify identity and authorisation.
- Private keys must never reach the browser.
- Payments and orders need authoritative, idempotent confirmation.
Choose what to keep and what to rebuild
When the interface, dependencies and healthy components can be isolated, selective rescue avoids wasted work. When code cannot be exported or critical logic is simulated, a focused rebuild may be safer.
What to check
- Keep the parts that can be verified.
- Compare diagnosis cost with rebuild cost.
- Record the decision before touching real data.
Prepare a useful technical review
Share an authorised demo link, repository or ZIP, the exact blocker, expected behaviour and the names of connected services. Never send passwords, tokens, .env files or API keys.
What to check
- Point to the exact failing flow.
- List the parts that already work.
- Describe the users and their main action.
Rescue or rebuild: what evidence do you need?
The decision depends on the flows you can verify and the cost of maintaining them. A working screen or a single error is not enough to decide.
Targeted completion
The project starts from a clean checkout, stores persistent data and enforces access boundaries. The fault is reproducible and contained, so the fix can be estimated and the rest of the journey tested.
Rebuilding one part
The interface and navigation are usable, but a critical flow is simulated or missing on the server. Assess whether that module can be replaced while keeping healthy parts and preparing data migration.
Assessing a rebuild
Critical parts cannot be separated or the project cannot be maintained within the required scope. Compare rescue and rebuilding, including data, integrations, testing and future operation, before choosing.
If source code or authorised access is missing, the assessment is incomplete. Recover that information before promising a solution or a price.
How to decide the next step
By the end, you should classify the project in one of three ways: suitable for targeted fixes, suitable for a focused rebuild of critical parts, or not recoverable without new source code. That decision comes before an estimate.
Do you have an app that stops at the demo stage?
Describe what works, what is missing and the outcome you need. The request is reviewed personally by Giambattista.