You built the whole thing. The screens work, the buttons do what they should, the preview looks exactly like the app you imagined. Then you hit "Publish" or "Deploy," and nothing happens. Or worse, you get a wall of red text about a dependency you have never heard of, and the app that worked thirty seconds ago in preview simply will not go live.

I see this almost every week. A founder tells me their AI app won't publish, and they are stuck staring at an error that reads like a foreign language, with no idea whether they broke something or the tool did. The frustrating part is that the app works. You can see it working. It just refuses to cross the finish line.

Here is what is actually happening, why AI builders get trapped in this exact spot, and a concrete path to get your app live, even when the builder's own deploy button keeps failing.

What "won't publish" actually means

When people say publish or deploy, they mean the same thing: taking the app that runs inside your builder's preview and putting it on the real internet where anyone can visit it.

Those are two different environments, and that difference is the whole story. The preview is a friendly, controlled sandbox. The builder has already set up everything the app needs to run there, so it just works. Publishing takes your code and rebuilds it from scratch on a real server, following stricter rules, with none of the preview's helpful shortcuts.

A build is the step in between. It is the app packing its bags: gathering every piece of code, every outside library it depends on, and assembling them into something a server can run. When people say the deploy "failed," what usually failed is this build step. The packing broke before the app ever got to ship.

Your preview is a rehearsal in a room the builder controls. Publishing is opening night on a stage it doesn't. The build is where the two fall out of sync.

That gap between "runs in preview" and "survives a real build" is where almost every publish failure lives.

Why AI-built apps get stuck here

AI builders are optimized to make the preview work. That is the demo, that is the moment you go "wow," and that is what keeps you building. The preview is the product they are really selling you.

The trouble is that a working preview and a shippable build are not the same achievement, and the AI does not always close that gap. Here is why these failures cluster so tightly around the publish step.

It invents libraries that don't exist

AI models sometimes reference outside code libraries (called packages or dependencies) that sound completely real but do not actually exist, or exist under a different name. In the preview this can slip by. At build time the server tries to download that package, cannot find it, and the whole thing collapses with a "module not found" error.

This is common enough that I wrote a whole piece on it, because a hallucinated package is not just a build annoyance, it is a security risk too. If you want to go deeper, see why AI-hallucinated packages are a security risk.

It mixes versions that don't get along

Your app depends on dozens of these packages, and each one has versions. AI-generated code frequently pins mismatched versions: package A expects version 2 of package B, but the code asks for version 4. Preview may tolerate it. A clean build refuses, and you get a dependency conflict.

It leaves out configuration the real server needs

The preview quietly fills in settings the AI never wrote down: environment variables (the private values like API keys and database addresses), build commands, the version of the underlying language to use. When you publish to a real host, none of that is assumed. The build looks for those settings, finds nothing, and fails. This overlaps heavily with the failures I see on launch day.

It writes code that only works in the sandbox

Sometimes the code depends on something specific to the preview environment: a file path, a hardcoded local address, a feature the sandbox provided for free. Move it to a real server and that crutch is gone.

None of this means you did anything wrong. It means the AI built for the room it could see, and the room where your app actually lives has stricter rules.

What a stuck deploy looks like

You do not need to read code to recognize which flavor of failure you are hitting. Here are the patterns I see most often.

  • The spinner that never stops. You click publish and the build just hangs, sometimes for ten minutes, sometimes forever. This usually means the build is quietly stuck downloading or resolving packages that will never resolve.
  • "Module not found" or "cannot resolve." The build is looking for a package or a file that either does not exist, was named wrong, or was never installed. This is the hallucinated-package or missing-dependency case.
  • "Build exceeded" or "out of memory." The build ran but ate more resources than the host allows, often because the app is pulling in far more than it needs.
  • It deploys, but the live site is a blank white page or an error screen. The build technically succeeded, but the app crashes the moment it runs, usually from a missing environment variable or a setting that existed in preview and nowhere else.
  • Preview works, publish shows an old version. The deploy is caching a stale build, so your latest changes never actually shipped.

If you are seeing the last two, that is the app running in the real world for the first time and immediately hitting something the preview hid from you.

How I'd get your app to actually ship

Here is the practical path. Some of this you can do yourself. I will be honest about where a real set of eyes saves you hours of guessing.

Step 1: Read the error from the bottom up

Build logs look terrifying because they dump everything. The actual cause is almost always near the bottom, in the last few lines before it quit. Scroll down. Look for a line with the word error, failed, or not found. That one line is usually the whole problem.

Copy that exact line. You do not need to understand it to act on it. If it names a package (something like Cannot find module 'react-fancy-thing'), you now know the culprit.

Step 2: Get your code out of the builder

This is the single most important move, and most founders never think to make it. Your app's code should live in GitHub, not trapped inside the builder's preview. GitHub is a free service that stores your code and its full history.

Getting your code into GitHub does two things. It gives you a real backup (if you have none yet, read what happens to AI apps with no backups). And it frees you from depending on the builder's flaky deploy button, because now any hosting service in the world can build your app directly from GitHub.

Most builders have an "export to GitHub" or "connect GitHub" option. If yours does, use it today, whether or not you are stuck. This is also the first step toward not being locked to one tool, which I cover in escaping Replit vendor lock-in.

Step 3: Deploy somewhere built for deploying

The builder's publish flow is often the weakest, least transparent part of the whole tool. Once your code is on GitHub, you can point a dedicated hosting service at it. These services exist to do one job well: turn your code into a live site, with clear logs when something breaks.

For most AI-built web apps, a host like Vercel, Netlify, or Render will connect to your GitHub repository, run the build, and show you exactly what happened at every step. The error messages are dramatically clearer than what the builder gives you, and that clarity alone often reveals the fix.

Step 4: Handle the missing configuration

If your build fails or your live site is blank, missing environment variables are the usual suspect. These are the private settings your app needs: database connection strings, API keys, and similar. In the preview they were invisible and automatic. On a real host you have to add them yourself, in the host's settings panel.

Make a list of every outside service your app touches (database, payments, email, login) and confirm each one has its keys entered on the host. A quick illustration of what a build config might need:

{
  "buildCommand": "npm run build",
  "installCommand": "npm install",
  "environment": {
    "DATABASE_URL": "set this in your host, never in the code",
    "STRIPE_SECRET_KEY": "set this in your host, never in the code"
  }
}

Those keys belong in the host's settings, never pasted into your code where anyone can find them.

Step 5: Fix the dependency mess (the part to be careful with)

If the error points at a package that does not exist or a version conflict, this is where founders most often go in circles. The tempting move is to paste the error back into the AI and ask it to fix the dependency. Sometimes that works. Often it swaps one broken package for another equally imaginary one, because the AI is repeating the same blind spot that created the problem.

This is the moment I would stop and get a real developer to look. Untangling dependency conflicts and removing hallucinated packages is fast and safe when someone knows what each library actually does, and slow and risky when you are guessing. If you have been stuck in the loop of the AI failing to fix its own bug, I wrote about exactly that trap in what to do when the AI can't fix the bug.

Step 6: Confirm the live version is really live

Once it deploys, do not trust that it worked. Open the live URL in a private browser window (so you are not seeing a cached copy), and click through your core flows: sign up, log in, the main thing your app does. A green "deploy succeeded" badge means the build finished, not that the app works for a real user.

The bigger picture: shipping is a skill the AI skipped

If there is one thing I want you to take from this, it is that a stuck publish is not a sign your app is bad. It is a sign the AI built beautifully for the preview and left the last mile, the part where software meets the real internet, unfinished. That last mile has its own rules, and the tools that make building feel magic tend to gloss right over it.

The good news is that this is one of the most fixable problems I deal with. Getting your code into GitHub and onto a real host gives you something the builder never did: a deploy process you control, with logs that actually tell you the truth. Even if you never touch the code, that shift alone takes you from "I can't ship" to "I can ship whenever I want."

If your AI app won't publish and you are tired of guessing at cryptic errors, that is exactly the kind of thing I untangle every week. I can find why the build is failing, get it deployed on a foundation that will not trap you again, and hand it back to you live. If you want to stop fighting the deploy button and just get your app in front of real users, let's talk about what yours needs.

Cover photo by Tim Gouw on Pexels.