Most Bolt apps that ‘don’t work’ work fine inside Bolt — and fail the moment they leave it. Bolt builds and runs your app inside the browser tab, in a kind of sandbox, so anything that needs a real server, real settings or a real backend only shows its gaps once the app is published somewhere real. Those gaps are specific and fixable; the screens Bolt built are usually worth keeping.
Settings the app needs — keys and addresses, known as environment variables — existed inside Bolt but were never entered on the hosting side, so the published app is running without them.
Bolt tends to build the visible part first. Secret keys end up in code that runs in the visitor’s browser, and anything that must be trusted — payments, permissions — runs where it can be tampered with.
An edit ran out of credits partway through, leaving a file that refers to something that was never written, or two versions of the same screen.
Add-ons that behaved in the browser sandbox but need a real server, a file system or a database once published.
The database is reachable from the app with no rules about who may read what, because the demo never needed them.
I take the exported project, run it outside the sandbox and reproduce the failure. Then I add what the sandbox was hiding: a real server for anything that must be trusted, the right settings on the host, and rules on the database about who may see what.
The screens Bolt generated stay. You get a repository, a published app that works from scratch, and a written note on what was actually wrong.
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, as an engineering review rather than a formal audit or certification. I look at authentication, authorization, exposed secrets, input handling, dependency risk and what your deployment leaves open. If you need a certified penetration test, I’ll tell you that instead of pretending otherwise.
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
It works when you use it. Production means it has to work when a stranger uses it, at 3am, on a bad connection, while something upstream is down — and you have to find out when it doesn't.
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
The eight security problems that recur in AI-generated apps, from missing ownership checks to leaked secrets — with a fix and a test for each one.
Read
10 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.