Cursor developer help · Your repository, any stack
Fix your Cursor-built app.
Cursor's agent wrote most of it, one session at a time, and now every change feels risky. A senior engineer reads the repository, fixes what is holding it back, and makes it safe to keep building, with Cursor or without it.
Photography is illustrative.
- Code
- Your own Git repository; Cloud Agents work on a branch and push or open a pull request
- Stack
- Whatever you chose: often Next.js or React, with Node, Python, Supabase or Postgres
- Hosting
- Your own: Vercel, Railway, AWS or similar
- Project memory
- Rules as .mdc files in .cursor/rules, and AGENTS.md
Who this is for
For founders and teams whose Cursor repository has outgrown its chat sessions.
Cursor is not an app builder with its own hosting. It is an editor whose agent works in a real repository, in whatever stack you picked. That is good news: there is nothing to export, and the code is already yours.
The usual trouble is consistency. Each agent session works from the files it searches for or that you attach, and a long chat is summarised once it fills the context window, so decisions made in one session are not always known to the next. Over a few hundred sessions that produces a codebase with several ways of doing the same thing, few tests, and changes nobody can predict. We bring it back to one design you can keep building on.
Failure modes
The ways Cursor-built apps go wrong.
These are what we look for first in a repository written mostly by Cursor's agent. They come from how agent sessions work, not from careless founders, and each one is fixable in place.
-
Three ways of doing everything
- What you see
- The same bug gets fixed twice. There are two sign-in helpers, each page loads data differently, and a small change touches ten files.
- What is actually wrong
- Each session sees only part of the code, and earlier decisions drop out when a long chat is summarised. The agent then writes a new helper instead of finding the existing one.
- How we fix it
- We map the architecture as it is, choose one pattern for each concern (data access, auth, errors, state), consolidate onto it with tests in place, and write the decisions down where the agent will read them.
-
Project rules the agent never reads
- What you see
- You wrote down how the project should be built, and the agent ignores it.
- What is actually wrong
- Cursor reads project rules from
.mdcfiles in.cursor/rules; a plain.mdfile there is ignored. A rule set to apply manually never triggers on its own, files a rule mentions are not pulled in, and Cursor advises keeping each rule under 500 lines. - How we fix it
- Short
.mdcrules with the right trigger (always, or by file pattern), anAGENTS.mdfor the overview, and the rules that matter most enforced by linting and tests, which the agent cannot talk its way past.
-
No tests, so every change is a gamble
- What you see
- Features ship fast, and something unrelated breaks each time. Nobody wants to touch the payment code.
- What is actually wrong
- An agent writes features faster than anyone writes tests for them. Without tests, the only safety net is undoing the last change.
- How we fix it
- Tests around what costs money when it breaks (sign-in, payments, data access) first, then continuous integration that runs them on every pull request, including the ones Cursor's agents open.
-
Secrets in the repository
- What you see
- An
.envfile is committed, or an API key sits in the code or the Git history. - What is actually wrong
- Cursor's default ignore list keeps
.envfiles out of the agent's view, but its documentation says the terminal and MCP tools cannot be blocked from ignored files, and nothing stops a key being written into code. Deleting a committed key does not remove it from Git history. - How we fix it
- Rotate every exposed key, move secrets to your host's secret store, and add secret scanning to CI so it cannot happen again.
-
Changes a checkpoint cannot undo
- What you see
- You restored a checkpoint, and the database or the live app is still broken.
- What is actually wrong
- Cursor's checkpoints revert files only, are stored locally and are separate from Git. A migration the agent ran, a package it installed or a deploy it triggered is outside them, and in the "Run Everything" mode commands run with no sandbox.
- How we fix it
- Development credentials that cannot reach production, database changes as reviewed migrations run from CI, and branch protection so nothing reaches production without passing checks.
-
Half-finished refactors and dead code
- What you see
- Two versions of the same component, files nothing imports, and a migration from one library to another that stopped halfway.
- What is actually wrong
- A refactor ends when the chat does, not when the work is complete, and an agent often creates a new file rather than editing the old one.
- How we fix it
- Static analysis to find what is unused, deletion with tests in place, and each half-done migration either finished or reverted, one pull request at a time.
Before you hire anyone
What to try yourself first in Cursor.
- Commit before every agent task. Cursor's own documentation says its checkpoints are local and separate from Git, and to use Git for permanent version control. Small commits let you undo one bad change instead of a day's work.
- Use the checkpoint, then Git. Restore a checkpoint from the chat timeline for the last few edits. For anything older, or anything outside the files, go back to a commit.
- Check your rules actually load. Rules belong in
.mdcfiles in.cursor/rules; a plain.mdfile there is ignored. Keep each one short and set how it applies. - One task per chat. Start a fresh chat for each task and attach the files that matter, rather than carrying one long conversation whose early instructions have been summarised away.
- Tighten the run mode while things are fragile. Use the Allowlist run mode rather than Run Everything, so a command you did not expect has to ask first. (Cursor itself says Auto-review is not a security boundary.)
- Scan the history for secrets. Run a secret scanner over the whole Git history, not just the current files, and rotate anything it finds.
How we work
How we work on a Cursor app.
There is nothing to export: your Cursor app is already in your repository. We work there, in branches and pull requests, with continuous integration that checks every change, whether it comes from us, from you or from a Cursor agent.
We leave rules files that describe the architecture we settled on, so your next Cursor session starts from it instead of guessing.
-
A free 20-minute call
You show us the Cursor app and tell us what is going wrong. We say what we expect to find, and whether a paid check is worth it yet.
-
Quick Security Check or App Readiness Review
A senior engineer reads the code and tests the running app: data access, keys, sign-in, payments, deployment.
You get Every finding in writing with its severity and fix; the review adds a keep, change or replace call for each part and a fixed quote.
-
Fixed-price fixes
Security & Data Hardening from $7,500, or Production Launch from $15,000, in your repository, with a test beside each fix.
-
Handover
Production kept apart from development, a deploy you can roll back, and notes so you, the tool or any developer can carry on.
Prices
Where to start, and what it costs.
-
App triage call
Free
20 minutes
-
Quick Security Check
$495
Delivered in 48 hours. The fee is credited toward the App Readiness Review.
-
App Readiness Review
$1,500 flat
5 business days. The fee is credited toward any fix booked within 30 days.
Fixes are priced after the check or review, at one fixed price before anything starts. The full price list and how fees are credited.
Proof
Who does the work.
A US software engineering firm. The founding team has taken a product off an AI app builder before (built, not yet in paid use) and runs a production telehealth platform on Supabase. We are an independent firm, not a Cursor partner or agency. Across the systems the team built and runs:
- 20,900+ automated tests across the systems the founding team built and runs
- 16,800+ CI runs automated builds and test runs on GitHub Actions
- 940+ merged pull requests across the same codebases
Counted from the repositories and CI history of the systems the founding team built and runs, 22 Sep 2026; each figure rounded down. How we counted
Questions buyers ask
Cursor questions, answered.
Can I keep using Cursor after you fix it?
Yes, and it should work better. We leave the project with one consistent design, rules that describe it, and tests and CI that catch an agent change that breaks something before it reaches production.
Will you rewrite it?
Rarely. Most Cursor-built code is ordinary code worth keeping. The review marks each part keep, change or replace, with the reason, before any work is priced.
Which stacks do you work in?
Every day: TypeScript, React and Next.js, Node, Python, Postgres and Supabase. If your app is built on something we do not know well, we say so on the first call rather than learn on your time.
Do you need my Cursor account?
No. We need access to the repository and, for the review, to the hosting and database. Your Cursor account stays yours.
Are you affiliated with Cursor?
No. Oracis is an independent US software engineering firm. We fix and finish apps built with Cursor, alongside apps built with Claude Code, Lovable, Replit and other tools.
What does it cost to fix a Cursor app?
The first call is free. The Quick Security Check is $495 and its fee is credited toward the App Readiness Review, which is $1,500 flat and credited toward any fix booked within 30 days. Security & Data Hardening is from $7,500 and Production Launch from $15,000, each at one fixed price set after the review. We never bill hourly on work nobody has sized. The full price list.
Send us the Cursor app.
The repository, what worries you about it, and when it needs to be live.