Built with Cursor?

Your Cursor app runs on your machine. That is the only place it has ever been tested.

Cursor is not the problem. You have a real repository, a stack you chose, and probably more code than a team of five would have written in the same months. What you are missing is everything that normally arrives with that much code: tests, review, CI, a deploy anyone else could run, and a second pair of eyes on the security assumptions. The tool moved the bottleneck. It did not remove it.

What actually breaks

• No tests, so every new prompt gambles the old featuresThe agent's verification loop is getting the current prompt to work, usually by you looking at the result in a browser. That is the entire QA process behind thousands of lines. So when a later prompt edits shared code, features you finished weeks ago break silently, and the first detector is a customer. Cursor will write tests if you ask; almost nobody asks while the demo is moving. The codebase grew far past what you can hold in your head, and there is no net under it.
• The agent edits files you never asked it to touchMulti-file edits are where the model's context runs out. The failure users report looks like this: it updates a function's signature in one file, then generates calls to the old signature elsewhere, or writes a fresh helper because it never found the one you already had. Two implementations of the same logic drift apart; you fix one, production runs the other. Forum reports also include the agent deleting code it judged unused. Reviewing a forty-file diff is precisely the work that was being skipped.
• Nobody has read the handlers that guard your dataThe model writes the permission check wherever it makes the demo pass, and in a demo the interface is what you watch. Whether the route handler behind the admin screen checks anything at all is a question only code review answers, and review is the step that got skipped. Nobody has read those handlers: not you, not a second engineer, not the model, which never sees the whole codebase at once. Until someone reads them, your authorisation model is a guess.
• Secrets pasted in to make the demo runWhen a missing key blocks the agent, the fastest route to a working demo is pasting the key into the code, and agents take fast routes. The key is now in git history, and sometimes in the client bundle too. Repositories with an AI coding assistant enabled have been measured leaking secrets at a higher rate than those without. Deleting the line does not fix it: history keeps it, forks keep it. Rotation is the only fix, and every key that ever landed in the repo needs it.
• A dependency tree nobody choseYour dependency list is a set of decisions nobody made. The model picks packages by statistical association, and a 2025 USENIX study of sixteen models found hallucinated package names in up to a fifth of recommendations, around one in twenty for the commercial models Cursor runs. Attackers register those invented names with malicious payloads; the technique is called slopsquatting. One in twenty is enough. And even the real packages were never compared against alternatives or checked for maintenance; you may have three libraries doing the same job.
• The deploy story is your shell historyCursor is an editor. It has no opinion about how your app reaches production, so the deploy story is whatever accumulated in your terminal: environment variables set once and never documented, a build that only works from your machine's working directory, CORS origins and callback URLs pointing at localhost. It works locally because your machine is the environment. The first deploy from a clean checkout, or by anyone who is not you, surfaces all of it at once, usually the week of launch.

How I work in a Cursor project

Your repository is already yours, which makes this the cleanest engagement I do. You add me as a collaborator, I work on a branch, and everything arrives as pull requests you can actually read, with the reasoning written in the description. Nothing reaches main without you seeing the diff. I leave the scaffolding behind as part of the job: CI that runs the acceptance test on every push, so the fix cannot silently regress the day after I leave. You keep using Cursor the whole time; stay on your own branches and we will not collide. The aim is not to replace your workflow. It is to put a floor under it.

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.

• ✓Replay any request from dev tools with another customer's record IDs and every route handler refuses it; the test asserting this ships in the pull request you merge.
• ✓A clean clone on a machine that is not yours installs, builds, and reaches production using only the documented commands, with no step that survives solely in your shell history.
• ✓Running git log -p across the full history turns up no live credential, the client bundle ships none, and every key that ever appeared in a commit has been rotated at its provider.
• ✓The agreed acceptance test, plus regression tests around everything the fix touched, runs in CI on every push and is still green after I am gone.

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 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