Your AI-built app works locally and breaks in production.

Your preview and your live site run the same code in different surroundings. The preview has its own settings, its own keys and often its own database. It also has exactly one user: you, already signed in, on a fast connection, looking at data you created. Production has none of that. When an app breaks after deployment, the cause is usually in those surroundings, and the code itself is often fine.

Surroundings can be checked without reading code. Start by writing down the exact failure: the page, what you did, what you expected, what happened, and whether it happens to every user or only to some. Then work down the table. The rows run roughly from the quickest cause to rule out to the slowest.

Most apps depend on a handful of values kept outside the code: the database address, keys for payments and email, the address of the site itself. Builders and laptops store these for you, which is why the preview works. The hosting service that runs your live site needs its own copy of each one, and it will not always warn you about a value that is missing. The app starts without it and fails at the first screen that needs it.

Make a two-column list: every setting the preview has, and the matching value on the live host. Look for gaps, for test keys where live keys belong, and for any value that still contains a preview or localhost address. While you are there, check that no private key sits in a setting the browser can read. A key that grants full access to your database or payment account belongs on the server side only.

Some services do more than answer when your app asks. A payment provider tells your app that a charge succeeded. An email service reports that a message bounced. These calls arrive at an address you registered with the service, and during building that address is often the preview. After you deploy, the service keeps calling the old address, your live app never hears about the payment, and from the customer's side the purchase did nothing.

Each of these services keeps a log of the calls it tried to make and the answer it received. Open that log after a test purchase on the live site. A call sent to the wrong address, or one answered with an error, shows where the chain broke. Confirm as well that production uses the live keys for each service and that the test keys stayed with the preview.

Missing settings, wrong addresses and test keys are yours to fix, and the table at the top is usually enough to find them. Write down what you changed and retest in a new account each time. If the app works after that, you may not need anyone.

Bring someone in when the fault involves who can see whose data, when records are being lost or duplicated, or when you have fixed the settings and the live app still fails in a way you cannot reproduce on demand. Those problems live in the code and the database rules, and guessing at them with more prompts tends to add faults. Our Diagnostic is a fixed-price written plan of what is blocking the launch and what to build next, credited to the build if you continue with us. Whatever you decide, your repo and accounts stay yours.