The gap in most Replit projects is between where you build (the workspace) and where real users use it (the deployment). The workspace is forgiving — it keeps your files, uses a practice database and sorts out the connection details for you. A deployment is a separate place with its own settings, its own database and, on the ‘autoscale’ type, no memory from one visit to the next. Almost every ‘it worked yesterday’ report traces back to one of those differences.
A setting, connection detail or database that the workspace supplied and the deployment doesn’t have. The deployment’s logs name it; the workspace never shows it.
Information saved into files or held in memory on an ‘autoscale’ deployment, which starts fresh each time. Anything that must be kept belongs in the database.
The app was tested against the practice (development) database; the live deployment uses a separate production one, which is empty or shaped differently.
Each fix is applied to the symptom the Agent was told about, so bugs move rather than close. The cause is usually one seam between two generated pieces.
Timers, background tasks or live updates that assume one always-on program, published to a type of deployment that scales up and down or sleeps.
I start from the deployment, not the workspace, because that is where it fails. I reproduce the failure, find the difference between the two environments that causes it, and fix it in the code so the deployment works from a clean start.
Where the Agent has been looping, I read the seams it can’t see — the boundaries between pieces generated at different times — and fix the cause once. You keep the Repl, the repository and the deployment.
Yes — all of them, plus Claude, Copilot and ChatGPT output. I don’t much care which tool generated the code. What matters is the application underneath it: the architecture, APIs, database, dependencies, and where things are breaking. Lovable and Bolt projects tend to need deployment and backend work; Cursor and Copilot projects more often need the seams between generated pieces checked.
Yes, and it’s one of the most common reasons people get in touch. "It works locally" is almost always an environment, configuration or build problem rather than a code problem, and those are findable.
Yes. If something is broken for real users right now, say so when you get in touch and I’ll treat it accordingly. I’ll want access to logs and the deployment, not just the code.
It depends on the work, so I don’t publish a price list. After a first look I quote a fixed price for the diagnosis, and any fix is scoped from the findings — so you know the cost before any work begins, and nothing changes partway through.
The service
The app half-works. You've described the bug to the AI six times, and each fix moves the problem somewhere else. At some point the loop stops being cheaper than reading the code.
Nine differences between your machine and production, in the order they break: env vars, build output, ports, database, CORS, paths, time, memory and secrets.
Read
9 min read
A practical method for debugging AI-generated code when prompting has stopped helping: reproduce it, read the seams, check the assumptions, and fix the cause.
Read
8 min read
It might need an engineer.
If you’ve spent hours asking AI to fix the same problem and you’re going in circles, stop fighting the code. Send me what you’ve got — I’ll figure out what’s wrong and tell you what I’d do next.
No cleanup. No judgment. The messy version is usually the useful version.