Built with Replit?

Your Replit app works in the workspace. The published version doesn't.

Replit Agent will take you from a sentence to a running full-stack app faster than almost anything else, and the workspace makes it feel finished: the preview runs, the database has data, sign-in works. But the workspace and the published app are two different environments, with different URLs, different secrets and different databases, and most of what breaks at launch lives in that gap. The failures are specific, repeatable, and fixable without abandoning Replit.

What actually breaks

• The link you shared was the dev URL, and it diedEvery workspace gets a temporary URL ending in replit.dev. It serves your app only while the workspace is active, it can change when you reopen the project, and by default it is public to anyone who has it (there is a Private development URL toggle under Networking, but you have to know to flip it). It looks shareable, so people share it, and it works until the workspace goes to sleep. A published deployment on replit.app or your own domain is a separate thing you set up deliberately.
• Production runs against a different database, which starts emptyEvery Replit App has two databases: a development one Agent builds against, and a production one Replit creates when you publish. Publishing carries your schema across (the tables and columns), not your data, so the live site comes up with empty tables. And Agent cannot read or write the production database directly, so prompting it to inspect your live data, or to repair it, gets you nowhere; you edit production data by hand in the Database tool, or fix the code and republish.
• The deployment has its own secrets, and one missing key takes the app downWorkspace Secrets and deployment secrets are separate stores. Replit's docs are inconsistent about how much syncs between them; the publishing pane has a Deployment secrets section, yet Replit's own troubleshooting guide lists secrets that did not carry over as a leading cause of a working preview and a broken published URL. The symptoms it names: undefined values, failed API calls, database connection errors, login and payment failures. When the preview works and the live URL errors, check the deployment's secrets first.
• Autoscale deployments forget everything between requestsAutoscale is Replit's default deployment type; Static Deployments cannot run an Agent app's backend at all. It serves your app from containers that spin up for traffic, run several copies under load, and scale to zero when idle. Anything on local disk or in process memory does not survive that: a SQLite file, uploads saved to a folder, in-memory sessions, a timer-based background job. Replit documents that filesystem writes in an Autoscale deployment are not persisted. Durable state belongs in the database or object storage.
• Publishing fails at the last step for reasons the preview never showedThe workspace is forgiving in ways a deployment is not. A server listening on localhost works in preview and does not work published; it has to bind 0.0.0.0. A run command that leans on the workspace's tooling fails in the deployment build. And Replit health-checks the app as it publishes: if your homepage takes more than five seconds to respond, the check times out and publishing fails at the final step, leaving you a log you have to know how to read.
• Replit Auth signs your customers into Replit, not just your appReplit Auth is quick: you ask Agent for it and get a working login with no setup, which is the only supported way to add it. The mechanism is that your customer signs in with a Replit account, on a Replit-branded page, with Replit acting as the OpenID Connect provider. For an internal tool, fine. For a consumer product it is friction you did not choose, and it ties your accounts to Replit's identity system: move hosting elsewhere and the auth layer has to be replaced wholesale.

How I work in a Replit project

Replit's Git pane connects your App to a GitHub repository you own; if that is not set up yet, it takes five minutes and I will walk you through it. From then on I work in the repository, not in your workspace: I clone it, make the fixes, and push, and you pull them back through the same pane, so the workspace, Agent and your deployment all keep working afterwards. During the sprint you park Agent, because it commits straight into the workspace, and two writers on one branch means someone's changes get overwritten. Secrets never touch the repository; they live in the Secrets pane and the deployment's own configuration, and that is where we fix them.

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.

• ✓The link your customers use is a published deployment, on replit.app or your own domain, and it still responds the morning after the workspace last went to sleep.
• ✓A record created on the live site lands in the production database and is still there after a redeploy; nothing the app writes drifts into the development database.
• ✓Every key and connection string exists in the deployment's own secrets, and a publish from scratch completes with no value that lives only in the workspace editor.
• ✓Customer uploads and signed-in sessions survive Autoscale scaling to zero and back, because durable state sits in the production database or object storage, never on a container's disk.

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 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.
• It runs on your laptop. It will not deploy anywhere else.
• Your AI feature is impressive when it works. You can't put it in front of a customer.
• The full The Launch-Blocker Sprint