Vibe coded an app? Here is what breaks when you deploy it.

On your laptop, everything is in one place. The code, the database, the files it saves and the secret keys it uses are all on the same machine, and that machine is you. Nobody else is logged in, nothing is behind a firewall, and the app restarts whenever you save a file.

Deploying means splitting that up. The code runs on a server you do not own, the database lives somewhere else, the files need a home, the keys have to be given to the server without being published, and strangers arrive with browsers you have never tested. AI coding tools are very good at the first situation and quietly assume it. The second is where the assumptions show.

None of this means the app is bad. Most of what breaks is in the environment around the code, not the code itself.

In rough order of how often we see them.

• Settings and secrets. The app reads API keys and database addresses from a file on your laptop. The server does not have that file, or worse, the keys were pasted into the code and are now in a public repository. The symptom is that it starts, then every request fails with an authentication or connection error.
• The database. Many AI tools start you on SQLite, a single file on disk. Hosting platforms often wipe that disk on every deploy, so your data vanishes, or two copies of the app write to two different files. You need a real database such as Postgres, and a way to apply schema changes without losing what is there.
• Logins and sessions. Cookies that worked on localhost fail on a real domain because of secure flags, domain settings or HTTPS. Password reset emails never arrive because there is no email provider configured. Sometimes the AI left a test login or an admin route open.
• File uploads. Photos and documents were being saved to a folder next to the code. On a server that folder is temporary or read-only. Uploads need object storage, and the app needs to know where it is.
• Domains, HTTPS and CORS. The frontend is on one address, the API on another, and the browser refuses to let them talk. Or the site works at the hosting provider address but not on your own domain because the certificate or the allowed origins were never set.
• Builds and dependencies. The app ran from a folder that had grown over weeks. A clean build on the server fails because a package was never saved to the project, a version drifted, or a step only ever ran on a Mac.
• Payments and webhooks. Stripe test keys are still in place, or the webhook that confirms a payment points at localhost. Payments appear to work in the browser but nothing is recorded, or real cards are charged in test mode and nothing happens at all.

It is not a feeling. It is a short list, and you can check most of it yourself.

• It is live on your own domain over HTTPS, and the hosting provider address redirects to it.
• Settings and secrets live in the hosting platform, not in the code, and the repository has never contained them. If it has, rotate the keys.
• The database is a managed service, backed up automatically, and you have restored a backup at least once to prove it works.
• Logins work on the real domain, password reset emails arrive, and there is no test account or open admin route left over.
• Uploaded files go to storage that survives a deploy.
• Errors are reported somewhere you will see them, not only in a terminal that is now closed.
• A fresh clone of the repository builds and deploys from scratch, so the next change does not depend on the state of your laptop.
• If money moves, live keys are in place, the webhook points at the live domain, and you have made one real small payment and watched it land.

Clone your repository into a new empty folder and try to run it there with nothing copied across. Everything that fails is something the server will also miss. Write each one down. That list is your deployment work.

Search the repository for the words key, secret, password and token. Anything that is a real value rather than a placeholder needs to move into environment settings and be rotated.

Open the app in a private browser window on your phone, over mobile data rather than your home network. Log in, upload something, and if it takes payments, make a small real one. Then deploy a trivial change and check the upload and the payment record are still there.

If the app passes all of that, you are in better shape than most. If it does not, you now know exactly what to fix, and in what order.

Get help when the fixes are outside what you can confidently test, which for most people means the database, the logins and anything involving money. Those are the parts where a wrong guess costs real data or real dollars.

Ask for a written review before anyone changes anything, covering what is sound, what is risky, and what to do first. Insist that the work happens in your repository under your accounts. Be wary of anyone whose first answer is to rebuild it from scratch. AI-built apps usually have more worth keeping than their owners fear, and a rebuild is often the expensive way to avoid reading the code.