10 Reasons AI-Built Apps Break When You Put Them Online

Building software has never been easier.

Today you can open Cursor, Replit or another AI coding tool, describe your idea in plain English, and have a working application within a few hours.

Then you put it online.

Suddenly users cannot log in. Images disappear. Database connections fail. The app crashes even though it worked perfectly five minutes ago.

The AI did not necessarily fail. You simply crossed the line between building software and running software. These are two very different problems, and most AI tools are only trained on the first one.

1. Localhost does not exist on the internet

When you run your app on your computer, it lives at an address called localhost. That is a special name that means "this machine, right here." AI tools often generate configuration that hardcodes this address:

APP_URL=http://localhost:3000

That line tells your app where it lives. On your computer it is correct. On a server in a data centre, localhost still refers to that server, not to your domain. So any link your app generates, any redirect it performs, any cookie it sets, all of it points to an address that does not exist on the internet. Users end up staring at connection errors or getting bounced to nowhere.

2. Environment variables are missing

When you build an app, it needs certain secret values to function. A database password. A Stripe API key. A secret used to sign login sessions. Storing these directly in your code would be a security problem because anyone who reads your code would have your keys. So instead, they are stored in a separate file called .env that lives only on your machine and is never shared.

The catch is that when your app runs on a server, that file does not come with it. The server has no idea what your database password is unless you explicitly tell it. This is one of the most common reasons apps go completely blank after deployment. The app starts up, tries to connect to the database, finds no password, and quietly crashes.

3. The database only exists on your computer

When you develop locally, the database runs on your machine alongside your app. It feels seamless because everything is on the same computer. When you deploy to a server, you are putting your app on a completely different machine that has never heard of your database.

You need to either set up a database on the server and point your app to it, or use a hosted database service. Either way, the database your app used during development does not come with it. This surprises a lot of people because locally everything just works, and it is not obvious that the database is a separate piece of infrastructure that also needs to be set up.

4. The database exists, but it is empty

Let's say you did set up a database on your server. The app still crashes. The reason is usually that while the database exists, it has no tables yet.

When developers build apps, they write files called migrations. These are instructions that tell the database how to set itself up: create this table, add these columns, define these relationships. These migrations need to run once before the app can use the database. Locally your AI tool probably ran them for you without making it obvious. On a fresh server nobody runs them unless you do it explicitly. The database is there but completely empty, so every query the app makes fails immediately.

5. Google and GitHub do not know your new address

If your app lets users sign in with Google or GitHub, those providers need to know where to send users after they log in. You configure this as a callback URL, something like https://myapp.com/auth/callback. During development your callback URL is something like http://localhost:3000/auth/callback.

When you go live, the provider still has the localhost address on file. When a user tries to log in, Google sends them to your live app, your app redirects them to Google, Google tries to send them back to localhost, and the whole thing fails. The fix requires logging into the Google or GitHub developer console and adding your live URL, which is something AI tools never remind you to do.

6. Uploaded files vanish after every deploy

Many AI-built apps store uploaded files in a folder on the local filesystem. Profile pictures, documents, images. This works fine during development. The problem is that on most hosting platforms, every time you deploy a new version of your app the server starts fresh. Any files saved between deploys are gone.

Users upload their profile photo and it works. You fix a bug and redeploy. Their photo is gone. This happens because the filesystem is not a reliable place to store persistent data on a server. Files should go to a dedicated storage service like S3 or Cloudflare R2, but AI tools often default to the simpler local approach because it works during development.

7. The app is listening on the wrong port

Every app listens for web traffic on a numbered port. Your local app probably uses port 3000 or 8080. On a hosting platform, the platform decides which port your app should use and communicates this through an environment variable, usually called PORT. If your app ignores that and listens on a hardcoded port instead, the platform cannot reach it and the app is effectively invisible even though it is running.

8. Background tasks never happen

Many apps need to do things in the background. Process a payment. Run a scheduled report. Resize an uploaded image. Send a notification. During development these often work because everything runs on one machine and there is no real distinction between the main app and any work it kicks off. On a server, background tasks usually need their own separate process called a worker that runs alongside your main app.

If nobody starts that worker, jobs pile up silently and nothing happens. Payments are placed but never processed. Images are uploaded but never resized. The app looks like it is working because it does not crash, but a whole category of features simply does nothing. Most hosting platforms require you to explicitly define and start these worker processes, which AI tools rarely mention.

9. Google crawls your site before your users do

Once your app is publicly accessible, search engine crawlers will find it, often within hours. For most apps this is fine. For apps with a large number of pages it can be an expensive surprise.

Crawlers like Googlebot do not browse your site the way a human would. They systematically request every page they can find, as fast as they can, around the clock. If you are on a hosting platform that charges per gigabyte of bandwidth transferred, a single crawl pass across thousands of pages can cost more than a month of real user traffic. The more successful your SEO, the more frequently they come back.

10. Production is less forgiving than your laptop

Your laptop is a comfortable environment. File paths are consistent. Permissions are relaxed. Services start in whatever order you launch them. Errors get logged to a terminal you are watching. When something goes wrong you restart it instantly.

A production server is different. File paths may differ. Services need to start in the right order or the app boots into a broken state. Errors get swallowed if logging is not configured. Permissions are stricter. Small inconsistencies that your laptop silently worked around become hard failures that take the app down.

The real challenge is not building

AI tools are already remarkably good at writing software. The part they are not good at is everything that happens after. Getting the database connected, the secrets configured, the migrations run, the file storage set up, the background workers started, and the whole thing deployed somewhere that stays up.

The Jetpacked approach

Jetpacked is built around a simple idea: getting an app online should not require becoming a DevOps engineer.

When you connect your repository, Jetpacked reads your code, figures out what kind of app it is, detects what services it needs, generates the configuration, runs your migrations, and gives you a live URL. When something still needs your input, a missing API key or a setting that cannot be guessed, it tells you exactly what it needs and why.

The goal is not just to put your app online. The goal is to make sure it still works once it gets there.