Short answer: do not start by fixing features. In the first 48 hours, protect what you cannot get back: rotate any secret that has ever been in the code or chat history, take a verified backup of your data, put limits on anything that costs money or touches other people's data, and switch off the risky parts you cannot yet trust. Then decide whether you have fixable bugs or prototype debt, and bring in an engineer before the next big feature, not after the next outage.
What should I do in the first hour?
Stop making changes. When an app built with Lovable, Bolt, v0, Replit or Cursor starts failing, the instinct is to ask the AI to fix it. Each new prompt can rewrite files you did not mean to touch, and you lose the last state that worked.
Do these four things first:
- Freeze the code. Make sure the project is in a Git repository you control, not only inside the tool. Tag the current version so you can return to it.
- Write down what is broken. Date, symptom, who is affected, how many users. Screenshots help. This is what an engineer will ask for first.
- Check who has access. List who can log in to the hosting, database, payment dashboard and email provider. Remove accounts that should not be there.
- Tell your users if data may be at risk. A short honest message is better than silence. Do it only once you know what you are saying.
How do I stop the bleeding in 48 hours?
Work through these in order. Each one removes a way to lose money, data or trust.
Rotate secrets. An API key that was ever pasted into a prompt, a chat, a public repository or front-end code should be treated as exposed. Rotate keys for your database, payment provider, email service and any AI provider. Put the new ones in environment variables on the server, never in the browser bundle.
Back up and prove the backup works. Export the database and file storage now. Then restore the copy into a separate empty environment and check that real records come back. A backup you have never restored is a hope, not a backup.
Put rate limits and spend caps on anything that costs money. AI API calls, email sending, SMS and file uploads are the usual ones. Set a hard monthly cap at the provider, and a per-user limit in the app if you can.
Switch off risky features. If you cannot explain who is allowed to do something, disable it until you can. Typical candidates: public sign-up without email verification, admin pages, bulk export, file upload, and any endpoint that deletes data.
Check the payment flow separately. If you take money, look at failed and duplicated payments in the provider dashboard. Confirm that a successful payment actually unlocks the product, and that a failed one does not. Do not experiment on live customers.
Turn on basic alerts. Even an email on every server error beats learning about problems from angry users.
Is this prototype debt or a bug I can fix?
This is the most useful question to answer before spending money. A bug is a specific thing that behaves wrongly. Prototype debt is the structure itself not fitting a live product.
Usually a fixable bug
- Scope: One screen or one flow fails.
- Cause: Clear and repeatable.
- Data: Records are correct, display is wrong.
- Access rules: Rules exist but have a gap.
- Payments: A webhook or edge case is missed.
- Changes: A new feature takes days.
- Environments: You can test safely.
Usually prototype debt
- Scope: Fixing one thing breaks something unrelated.
- Cause: Nobody can say why it works when it works.
- Data: The same fact is stored in several places and they disagree.
- Access rules: Rules are checked only in the browser.
- Payments: Payment state is guessed from the page, not confirmed by the provider.
- Changes: Each change takes longer than the last.
- Environments: Testing means editing the live app.
If most of your answers match the prototype debt list, more prompting will not help. The app needs hardening or partial rebuilding, and that is an engineering decision, not a prompting one.
We see this pattern in our own work. When we picked up Karbon Shortcuts, the main problems were a wrong architecture and a broken, unstable Stripe integration. We took it over and built new features on top. You can read more in our Karbon Shortcuts case.
When should I call for help?
Call an engineer when any of these is true:
- Real customers' data or money is involved and you cannot explain how access is controlled.
- The same kind of failure has happened twice.
- You are afraid to deploy.
- Payments are inconsistent: charged but not unlocked, or unlocked but not charged.
- You want to add a major feature and the last three small changes each broke something.
- You cannot say where the data lives or who can read it.
You do not need to rewrite everything. A short review will tell you what is wrong, what is cheap to fix and what is not. If you want an outside read, Vibe Code Rescue is exactly this: rescue, hardening and takeover of apps built with AI tools. You can book a free 30-minute intro call, and the price after that depends on what is needed.
What should I hand an engineer on day one?
Preparation shortens the first week more than anything else. Bring:
- Repository access (read access is enough to start), plus the tool project link if the code lives there.
- Hosting and database access at the lowest level that lets them look, ideally read-only.
- The incident note from the first hour.
- A list of what must not break: sign-up, login, payment, the one report your biggest customer uses.
- Third-party accounts: payment provider, email, analytics, domain registrar.
- Prompt and chat history, if you still have it. It shows why odd code exists.
- The next three features you want, in order. The architecture should be judged against what you need next, not only today.
Can an AI-built app really become production-ready?
Yes, in many cases. A design or a working front end built in an AI tool is a legitimate starting point. We have worked with clients who came with a Lovable design and needed the rest: for ThePokeLlama we built the full backend, deployed it and ran sprint-based development. Wyzor AI followed the same pattern. The tool got the idea visible quickly. Engineering made it hold up.
What does not work is treating the first generated version as the final architecture while paying users depend on it.
What is the one thing to do today?
Take the backup, restore it somewhere safe, and rotate the keys. Everything else can wait a day. If you want a second pair of eyes on what comes next, book a free 30-minute intro call and bring your incident note.
