You described your product to Lovable, Bolt, v0 or Replit. An app appeared. It looked great in the demo. Then real people started using it, and things went wrong: logins failing, data missing, a payment that charged twice, a page that went blank.
This is common, and it does not mean you did something wrong. The app was built to look right on the happy path with one user. Real use is messier. This post lists what I check first when someone asks me to look at an app in this state, and how you can test each one without writing code.
I run a service called FixedLaunch for exactly this situation, so I have an interest here. Everything below you can do yourself.
First, protect what you have
Before you fix anything, do three things.
- Make a copy. Export or back up your project and your data. If the builder lets you connect to GitHub, do that now.
- Write down what is broken. For each problem, note what you did, what you expected and what happened. Screenshots help.
- Stop collecting sensitive data if you suspect a security problem. Pause sign-ups until you have checked item 1 below.
1. Who can see whose data
This is the most serious problem, so it comes first.
In many generated apps, the database lets any signed-in user read other people's records, or sometimes lets anyone read them with no sign-in at all. The app screens hide the data, but the data itself is exposed.
Test it: Create two test accounts. Add some data in account A. Sign in as account B and try to reach A's data, including by pasting A's page address into B's browser. If B can see it, you have a permissions problem.
Fix it first. Nothing else matters if customer data is open.
2. Secrets in the wrong place
Apps connect to outside services using keys, which work like passwords. Generated apps sometimes place those keys in code that runs in the visitor's browser, where anyone can read them.
Test it: Open your live site in Chrome, right-click, choose "View page source", and search for words like "key", "secret" or "token". If you see a long string beside one of them, ask a developer whether it belongs there. Keys for payments and AI services must never appear in the browser.
If a key has been exposed, replace it with a new one from the service's dashboard.
3. Sign-in and sign-up edge cases
The demo path is: sign up, land on the dashboard. Real people do other things.
Test these by hand:
- Sign up with an email that already has an account.
- Click "forgot password" and follow the whole email through.
- Sign in on your phone, then on a laptop.
- Open the app in a private window and visit a page that should need a login.
- Click the confirmation link after it has expired.
Write down every case that breaks or shows a confusing message.
4. Payments
If you take money, test the whole route, not only the button.
Test it: Use your payment provider's test mode and run through a purchase, a failed card, a refund and a cancelled subscription. Then check that your app and your payment dashboard agree on what happened. A common fault is an app that marks someone as paid when they return to your site, instead of when the provider confirms the payment. Someone can then reach the paid area without paying.
5. What happens when something fails
Generated apps often handle success well and failure badly. A slow network, an outside service going down or an empty result can leave the page blank or the user stuck.
Test it: Turn off your wifi in the middle of an action. Submit a form with every field empty. Submit it twice, fast. Paste a very long piece of text into a text box. Watch what the app does. A good result is a clear message. A bad result is a frozen screen, a duplicated record or an error with no explanation.
Ask whether you will find out when something breaks. Without error tracking, you hear about failures from angry users, if you hear at all.
6. Real data and real load
Your demo had a handful of records. Real use has hundreds or thousands, and some pages slow down sharply.
Test it: Add a few hundred fake records and see whether the main screens still load quickly. Test on a mid-range phone with a normal mobile connection, not only your laptop. Check that the app saves your data somewhere that does not reset when you update it. Ask your builder where the database lives and whether anything backs it up.
What a developer adds
If these tests turned up problems, a developer can usually fix them in an order that matches risk: data access, secrets, payments, then everything else. Rewriting the whole app is the exception. In most cases the visible part of the app is fine and the work sits underneath it.
A good developer will also set up the dull but useful things: backups, error alerts, a proper domain and email, and a record of what changed. These stop a small problem from becoming a bad week.
FixedLaunch offers a diagnosis for USD 149 that tells you what is wrong and what a fix would cost, and fix sprints start from USD 750. You can find it at fixedlaunch.com. If your app needs more than a repair, the cost breakdown post explains what a proper rebuild involves.
FAQ
Should I rebuild the app from scratch? Usually not. Start with the checks above. Rebuild only if the foundation cannot be repaired, such as when the data is stored in a way that cannot support your plan.
Is it safe to keep running while I fix it? It depends on what the app holds. If it handles payments or private data and you found an access problem, pause sign-ups first.
Can I keep prompting the AI builder to fix these? Sometimes. For layout and small features it works well. For permissions and payments, a builder that cannot see the whole picture can change one thing and break another, so have a person review the result.
How long does a repair take? It depends on what you find. A short diagnosis tells you before you commit to anything.
Will I lose my work? You should not. Back up first and keep your account and code in your own name.
Next step
Run the app readiness check. It takes a few minutes, scores your app against the basics above and shows your top fixes. If you want a person to look, send me the result through the hire page.