Deploy keeps failing?

It runs on your laptop. It will not deploy anywhere else.

An AI coding tool builds against the machine in front of it. Your laptop has the .env file, the right Node version, a database with every table, and a pile of installed packages that has survived months of tweaks. Production has none of that. So the app runs perfectly for you and fails the moment it leaves your machine. That is not one bug; it is a category, and on nearly every project I see, the failures land in the same few places.

What actually breaks

• The environment variables only exist on your laptop.env files are read by your local dev server and, rightly, never committed to git, so nothing in them reaches the hosting platform. Every variable has to reach the host's own settings, typed in or imported in bulk, and a missed one does not always fail loudly: the code reads undefined, the build can still pass, and the first request that needs the value breaks on a customer. Compare your local .env against the host's list line by line; the missing one is usually the variable added most recently.
• The build leans on state that lives only on your machineThe repository is not the whole story on your machine. There are files git never saw, packages installed by hand but missing from package.json, a lockfile that no longer matches it. One classic: macOS treats file names case-insensitively and Linux does not, so an import written as ./Header resolving a file saved as header.tsx works locally and dies with module not found on the build server. Without CI there is no neutral machine proving any of it, so every deploy is a coin toss.
• Nothing pins the Node versionYour laptop runs whatever Node you installed a year ago; the platform runs its own default, and nobody wrote the number down. Syntax your local version accepts can fail to parse on an older runtime, and native modules are compiled against a specific Node ABI, so a version jump can make a dependency that installed cleanly refuse to load. The fix is dull and total: declare the version in package.json engines, set it in the host's settings, and use the same one in CI.
• The migrations never ran against the production databaseLocally, the tool created tables as you built, so your database matches the code exactly. The production database was provisioned once and never caught up. With Prisma, migrate dev creates migration files and applies them to your local database only; production needs migrate deploy run against it, usually as a step in the release. Skip it and the app still boots, pages that read nothing render fine, and the first real write fails with a table does not exist error.
• localhost is hardcoded somewhere that mattersAI tools write the URL that works at the moment of generation, and locally that is http://localhost:3000 or :5173. It hides in fetch calls, WebSocket URLs, and CORS allow-lists. Deployed, the frontend asks for an API on the visitor's own machine, which does not answer, so every request fails while the page itself loads fine. Each instance has to be found and replaced with a base URL that changes per environment. If sign-in bounces people to a localhost address, that is a redirect URL problem, covered on the sign-in page.
• The build passing is not the deploy workingA green build proves the code compiles, not that it survives the platform's runtime rules. Serverless hosts cap how long a request may run, a ceiling often measured in seconds. Locally, a big import or a chain of AI calls just takes a while; deployed, the same request is cut off mid-work and the customer sees a timeout. None of this shows in the build log, so test at the live URL. If saved files are vanishing, that is serverless storage, covered on the Replit and v0 pages.

How I work on a failing deploy

Reproduction comes first. I clone the repository onto a clean machine, one that has never seen your .env or your hand-installed packages, and try to build, run, and deploy it. Everything that breaks at that point is the real list, and it is usually longer than the one error you have been staring at. Fixes go in dependency order: pin the Node version, inventory every variable and get it onto the host, commit the migrations and attach them to the release step, swap hardcoded URLs for per-environment configuration. The final step is CI, so every future deploy builds from a clean checkout and can never again depend on anything peculiar to your laptop. I will need access to the repository and the hosting account; both stay yours.

What “done” looks like

We agree one of these in writing before you pay anything. If it passes, the sprint passed. If it doesn't, you get a full refund and keep the work.

• ✓Pushing to the main branch builds and deploys automatically, and the code customers run comes out of CI's clean checkout, never off anyone's laptop.
• ✓Every variable the app depends on is set on the host and documented in the repository, with a startup check that names the missing one instead of breaking on a live request.
• ✓The production database schema matches what the code expects, and every future change reaches it through a migration run in the release, never applied by hand.
• ✓No shipped code points at localhost: API base URLs, allowed origins, and redirect targets all resolve to your production domain.

Other things that block launches

• Your Lovable app works in the preview. It breaks in production.
• Stripe took the money. Your customer got nothing.
• Your Bolt.new app runs fine in the preview. The published version doesn't.
• Your Replit app works in the workspace. The published version doesn't.
• Your v0 app looks ready to ship. The part that breaks is the part you can't see.
• Your Base44 app works when you use it. It breaks when your customers do.
• Your Cursor app runs on your machine. That is the only place it has ever been tested.
• Your customers can see each other's data. It is never just the one screen you found.
• Users can't sign in. It worked every time you tested it.
• Your AI feature is impressive when it works. You can't put it in front of a customer.
• The full The Launch-Blocker Sprint