My app worked in the preview. Why does it break once it's live?

Because the live app runs somewhere else, with different settings, real data, and real customers. The preview runs on your test data and your login, so it can’t show those differences. Five habits prevent most of the breaks they cause: (1) keep a list of what differs once it’s live, (2) keep secret keys out of the code, (3) try each change on a copy of the live app first, (4) treat changes to stored data as their own step, and (5) know how to undo a release before you make one. You can do each of them by asking the AI or changing a setting.

Why the preview hides these problems

The preview is built for one person trying things. It has the records you created, a login you set up, and a fast connection. When something fails there, you see it at once and try again.

In the live app, strangers sign up at the same time, with names and details you never typed. They pay with real cards. They use phones and browsers you never tried. When something fails, you usually hear about it from them.

Builders on Reddit report the same pattern. One wrote that their app worked well in preview mode, then five days of deploy attempts kept ending in crashes (opens in a new tab). Another described the gap in time: a quick utility took 10 minutes, and commercial-grade usability, reliability, and integrations took a long, sometimes very frustrating time (opens in a new tab).

Most of these breaks come from a short list of differences between the two places.

What changes once your app is live

Settings and secret keys. Your app reads settings that aren’t in the code, such as the address of its database and the keys for your payment and email services. The live app has its own copy of these settings. A key that exists in the preview can be missing or different once it’s live.

Test mode and live mode. Payment and email services usually give you a test mode, where nothing real happens. The live app has to use live mode, with live keys. A payment flow that worked with a test card can fail on the first real one.

Real data. The preview had a few tidy records. Real customers leave fields empty, paste long names, and keep accounts from before your last change. Code that assumed tidy data can fail on the first messy record.

Changes to stored data. Sometimes a change alters how your data is stored, such as splitting one name field into two. In the preview, there was little data to convert. In the live app, the change has to work on every record you already have.

Your own login. You usually test as the owner, who can usually see everything. A customer has fewer permissions. A page that works for you can be blank or refused for them.

Five habits before your next release

A release is the moment a change reaches your live app.

1. Keep a list of what differs once it’s live

Start a short file with the settings your live app needs. Write each setting’s name and what it’s for, never its value. For example, write “Payment key, live mode” or “Email sender address.”

Add the services that must be in live mode, and anything else that is set up differently, such as a custom web address. Before each release, ask the AI: “Does this change need a new setting, or a change to one on this list?” If the answer is yes, add it to the live app before the change is released.

2. Keep secret keys out of the code

A secret key is a password your app uses to reach a paid service. It belongs in the secrets settings your platform provides, not in the code and not in a chat.

Keep separate keys for testing and for the live app. If a test key reaches your live app, payments may go nowhere. If a live key reaches a test, the test can charge a real card. Whether your app is safe to keep building on covers how to check for keys already written into your code.

3. Try each change on a copy of the live app first

A staging environment is a private copy of your live app. It has the same kinds of settings, with test keys in place of live ones, and data that looks like real data without real customer details. A change runs there before any customer sees it.

On the copy, sign up as a new customer, not as yourself. Try the flows that bring in money, such as signup and payment, on a phone as well as a computer. Saved tests can repeat these checks on every change, and how to test an AI-generated product explains how to build tests you can trust.

4. Treat changes to stored data as their own step

Before any change, ask the AI: “Does this change alter how stored data is kept?” If it does, take the steps below before releasing it.

Back up the live data first. Try the change on the copy, with data that looks like your real data. Then ask how the change would be undone if it went wrong. A change to code can usually be reversed in minutes. A change to stored data can be harder to reverse, because the old data may already be gone.

5. Know how to undo a release before you make one

Many platforms and hosting services keep earlier versions, so you can go back to the last one that worked. Learn the steps while nothing is broken.

For the first hour after a release, watch for errors. Log in as an ordinary customer and try the main flows yourself. If you set up error alerts, read them that day, not at the end of the week.

When the live app breaks anyway

Undo first. Go back to the last version that worked, so customers can use the app while you look. Find the cause after that, not under pressure.

Ask what changed. Ask the AI to list every change since the last version that worked, including settings and stored data. The cause is usually on that list.

Reproduce it on the copy. If you can make the problem happen on purpose, you can fix it and confirm the fix. Then add a test, so the same break is caught before the next release.

How Forged handles this

Forged builds every change in your repository, where your code is kept. Each change arrives as a pull request, a proposed change that shows how each part of it was verified before it reaches your live app.

Dimension	The Forged approach
Changes to stored data	A plan or task that would change the database shows a Changes data or roles warning before you accept it
New permission boundaries	The same warning, with a sentence saying why
What couldn’t be checked	Marked Can’t be checked here, with the reason, and the work is held
What ran during the build	Each command the build ran, and the result of each
Your own checks	GitHub’s results on the pull request, shown beside Forged’s
Keys left in the code	A Product Health check lists leaked secrets it finds

Risky changes are named before they’re built. When a feature or task would add a change to stored data, or a new boundary on who can see or do what, Forged marks it with an amber Changes data or roles warning. You see it while you review the plan, before any code is written.

What couldn’t be tested is said plainly. Before building, Forged lists how each change will be judged finished, and you approve that list. Forged builds and checks each change in its own build environment, which is not your live app. When an item on that list can’t be checked there, it is marked Can’t be checked here, with the reviewer’s reason. That item holds the work until it is settled.

You see what ran. Each step of the build lists the commands it ran and the result of each, such as “tests and build passed”. When two features both change your stored data, Forged puts the two changes in order with the commands your project already uses. If no GitHub checks ran on a pull request, Forged says so, which tells you nothing outside Forged tested it.

Your questions, answered

Do I need a staging environment?

Yes, once customers depend on your app.

A copy of the live app is where a change can fail without a customer noticing. Some platforms create one for you, so ask yours.

Why does it work for me and not for my customers?

Usually because you’re logged in as the owner.

Your account can see and do more than a customer’s. Create an ordinary customer account and test with it, on a phone as well as a computer.

Should I undo a bad release or fix it quickly?

Undo it first.

A quick fix made under pressure can break something else. Go back to the last version that worked, find the cause, and release the fix once it has passed on the copy.

Will moving to GitHub stop this?

Not on its own.

A repository keeps every version of your code, which makes undoing a release and comparing versions much easier. You still need the five habits. Moving to a normal GitHub workflow explains how to make the move.

Know what a change touches before your customers see it

Name the change you were about to release, and connect Forged to your repository.

Forged names changes to stored data and permissions before the build. The pull request then shows what was checked, what ran, and what couldn’t be checked.