Shipped fast with Cursor. Now nobody's sure what's in there.

What Cursor does well

Cursor keeps a human in the loop, so the output tends to be idiomatic and architecturally sane — the engineer chose the shape. What accumulates instead is volume: features built faster than anyone documented them, patterns that diverge across the codebase, and a growing gap between what the team believes is there and what is.

• Whatever the team already used
• Multiple patterns for the same problem
• Partial or absent test coverage
• Dependencies added per feature
• Deployment set up once, early on

• 01

  Three ways to do the same thing

  Different sessions produced different patterns for auth checks, error handling and data fetching. Each is fine; together they mean no rule can be enforced or reasoned about globally.

• 02

  Coverage where it was easy, not where it matters

  Tests exist for pure functions and not for checkout, permissions or the billing webhook. The coverage number looks reassuring and protects nothing that would hurt.

• 03

  Dependencies nobody chose deliberately

  Four date libraries, two HTTP clients, an abandoned package pulled in for one helper. Each was a reasonable local decision; the aggregate is a supply-chain and bundle-size problem.

• 04

  Undocumented assumptions

  Code that only works because of an invariant held elsewhere, with nothing recording it. The next change breaks something unrelated, and the fix takes a day of archaeology.

• 01

  Secrets in the client bundle

  API keys inlined into frontend code because the prototype had no server to hide them behind. Anyone can read them with view-source, and rotating them is the first thing we do.

• 02

  Authorisation checked in the UI

  The admin button is hidden from non-admins, and the endpoint behind it is wide open. Hiding a control is not access control, and this is the single most common serious finding.

• 03

  No migration history

  The schema exists because someone clicked through a dashboard. There's no record of how it got that way and no safe path to change it, so the first production schema change is terrifying.

• 04

  Nothing to catch a regression

  No tests, so the next AI-assisted edit that breaks checkout is discovered by a customer. This is what makes generated codebases feel fragile — not the code quality, the absence of a safety net.

1. 1

   Architecture review — 3 to 5 days

   We read the whole codebase and report the divergent patterns, the untested critical paths, the dependency risks and the undocumented invariants — ranked by what would hurt most in production.

2. 2

   Converge the patterns

   One way to do auth checks, error handling and data access, applied across the codebase, with lint rules that keep it that way once we've gone.

3. 3

   Test what would hurt

   Coverage targeted at money paths, permissions and the core loop first. Coverage percentage is a byproduct, not the goal.

4. 4

   Security and dependency pass

   SAST and dependency findings triaged and fixed, secrets audited, and the duplicate libraries consolidated.

5. 5

   CI, environments, monitoring

   GitHub Actions with pre-merge gates, a real staging environment, Sentry and alerting — plus written architecture notes so the assumptions stop being tribal knowledge.

1. Step 1 · Validate

   30-day Sprint

   Prove the use case before you commit. Working prototype on real data, eval scores, and an honest signal in 30 days. Fixed scope, fixed fee.

   $4,500 fixed

   Learn more
2. Most teams land here

   Step 2 · Build

   Prototype → Production

   Turn the validated prototype into a real product. Auth, DB, payments, tests, monitoring, deployed. Sprint fee credits toward this engagement.

   from $6,000

   Learn more

3. Step 3 · Scale

   Managed Retainer

   Ongoing operation, eval cycles, model iteration, and cost guards. We keep the system improving so your team can focus on growth.

   from $750/mo

   Learn more

FAQ

Cursor Codebase to Production: your questions.

• Is this just a code review?

  It starts as one and ends in shipped changes. A report alone tends to sit in a backlog; the value is in converging the patterns and adding the tests, which is work your team could do but usually can't prioritise against feature pressure.

• Our team wrote this. Will this feel like a critique?

  It's a critique of the codebase, not the team — and most findings are the predictable consequence of shipping fast with AI assistance, which is what you were trying to do. We write it the way we'd want to receive it.

• Can you work alongside our engineers?

  That's the better version of this engagement. We pair on the first slice so the conventions are agreed rather than imposed, then split the remaining work.

• How long does it take?

  The review is 3 to 5 days. The remediation depends entirely on size — the review gives you a scoped, sequenced plan with estimates before you commit to any of it.

• Bolt to ProductionBolt gets you to a running product in an afternoon. We add the things it never had to think about — real auth, migrations, payments that can't double-charge, and a test suite that survives your next prompt.Read
• Lovable to ProductionLovable is very good at producing an app that looks and feels finished. What it can't know is which of your tables must never be readable by another customer — and that's the finding that stops enterprise deals.Read
• v0 to Productionv0 output is the best-looking starting point in the category, and it is almost entirely frontend. The work is building the system underneath it — and doing that without throwing away the UI you liked.Read