Cursor is different from the other tools on this page — it's not a hosted platform that provisions a database and deploys for you, it's an AI pair programmer inside an editor. That makes it more flexible and also means none of the guardrails a platform like Bolt or Lovable bakes in by default exist here at all — whatever gets built depends entirely on what got asked for, prompt by prompt.
The most common issue isn't one dramatic security hole, it's accumulated inconsistency: a codebase built across dozens of separate prompts and sessions, each solving its own slice of the problem without full context of what came before.
The Cursor-specific issues we see most
Inconsistent architecture — the same kind of problem solved three different ways because each prompt had a different, partial view of the codebase
Environment and config drift — a .env.example that no longer matches what the app actually reads
Dependency bloat — packages added mid-session for an approach that was later abandoned, never removed
Tests written to pass against current behaviour, not to catch regressions — including current behaviour that's wrong
No consistent error-handling strategy — every route handled differently depending on which prompt generated it
Secrets pasted directly into code during rapid iteration and left there once the feature worked
Zero deployment story by default — Cursor writes code, it doesn't provision hosting, CI, or environment separation
A checklist you can run yourself
Give this a real go before reaching out — the people who can fix it themselves were never going to hire us, and the ones who read it and realise the scale of the job usually do.
Pick three similar features (three API routes, three form handlers) and check whether they're actually built the same way, or three different ways.
Diff your .env.example against what your code actually reads — check for variables that exist in one but not the other.
Run a dependency audit and look for packages that aren't imported anywhere — remnants of an abandoned approach.
Read your test suite and ask whether it would actually catch a regression, or whether it just re-asserts whatever the code currently does.
Search your git history for anything that looks like a real API key or secret, even in an early commit that was later "fixed."
Check whether you have any CI pipeline at all, or whether "deploy" currently means someone running a command from their machine.
Confirm development and production — if both exist — use separate databases and separate credentials.
When to get help
Worth getting a second pair of eyes on this once real users are on it, payments are involved, you're handling anyone's personal data, or someone other than you will need to maintain this going forward. Below that bar, the checklist above will get you most of the way.
Read the full AI app rescue guide, or see the checklist for Bolt, Lovable, v0 or Replit.