Fix a Replit app that stalls or breaks under real users.

With most tools the code is written in one place and run in another, so the founder learns early where things live. On Replit both happen in the same account, and the agent can create a database, store a key and start the app without you having to know where any of it went. That works well up to the day other people depend on it.

The trouble we see most often comes from that hidden layout. A change shows up in the workspace and customers do not see it. Customer records vanish or reset. Uploaded files are there in the morning and gone by the afternoon. People get signed out for no reason they can see. Each has an ordinary explanation, and the table pairs each with a question to answer.

Think of the project as two things. One is the workspace, where you and the agent make changes and press run to try them. The other is the published app at the address you gave your customers. Publishing takes a picture of the workspace at that moment. Later edits stay in the workspace until you publish again, which is why a fix can look finished to you and be invisible to everyone else.

This separation is useful once you know it is there, because it lets you try changes away from customers. Make it deliberate. Keep a short log with three columns: the date, what changed, and whether it has been published. Before telling a customer something is fixed, open the public address in a private browser window, signed in as an ordinary test user, and check it there. The run button in the workspace only shows you the workspace.

A running app is a program that can be stopped and started again at any time: when you publish an update, when it crashes, or when the platform moves or pauses it. Anything the program was only holding in memory is gone after a restart. Anything it wrote into its own folder may be gone too, depending on how the app is published. With one user who rarely leaves the page, you may never see a restart. With many users across a day, restarts land in the middle of somebody's work.

Three things are worth tracing. Uploaded files should go to storage built for files, with the database keeping a reference to each. Sign-in sessions should be kept in the database or a similar store, so a restart does not sign everyone out. Scheduled work, such as a reminder email sent every morning, needs something that runs it on time even if the app was asleep. Ask the agent how your app handles each of these and ask it to point to the code. Then test the first two directly: upload a file and sign in on the published app, publish a trivial update, and see whether the file and your session survived.

A fix that was never published, a key missing from one of two places, an app published in a mode that lets it sleep: you can settle these yourself with the table above, and no engineer is needed.

Get someone in when customer records have been lost or mixed, when you cannot say with confidence which database the live app is using, or when the app falls over as soon as more than a few people use it at once. Those need a person to read the code and the data together, and further agent sessions on a live database carry real risk. Our Diagnostic is a fixed-price written plan covering what is safe as it stands, what has to change before more users arrive, and whether staying or moving suits you better. The fee is credited to the build if you go ahead. Your Replit account, your code and your data stay with you.