---
title: "Cursor App Not Working? When to Hire a Developer to Fix It"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-11-12"
category: "Cost & Planning"
tags:
  - cursor app
  - fix cursor app
  - hire developer for cursor app
  - vibe coded app rescue
  - AI generated code review
excerpt: "A Cursor app that is breaking is usually a repair job, because you already own a real repository. Here is how to tell a repair from a rebuild, who to hire, and what the market charges."
reading_time: "12 min read"
canonical_url: "https://kanopylabs.com/blog/cursor-app-not-working-when-to-hire-a-developer-to-fix-it"
---

# Cursor App Not Working? When to Hire a Developer to Fix It

## The Short Answer for a Cursor App That Stopped Working

Hire a developer for your Cursor app when it holds real user data or takes real money and nobody has checked who can read what, when the agent keeps breaking features that worked last week, or when the app has never run anywhere except your laptop. If the trouble is one bug or one tangled feature, a better rules file or a freelancer for a few days will fix it. Most of the time the job is a repair of the code you already have, and a repair costs far less than a rebuild.

That last point is what separates Cursor from the hosted builders. Cursor is an editor. Everything the agent wrote sits in files on your machine, in a normal framework such as Next.js or Expo, and any developer can open it. A Bubble app cannot be exported at all, and a Lovable app starts life on Lovable's own setup before you pull it out. I covered that case in [when to hire a developer for a breaking Lovable app](/blog/lovable-app-breaking-when-to-hire-a-developer-to-fix-it). With Cursor there is nothing to export. The repository is the app.

The other side of that freedom is that nobody made the boring decisions for you. Cursor did not pick a host, switch on database backups, or put a login in front of your admin page. It wrote what you asked for. Whatever you did not know to ask for is probably missing.

![Laptop on a desk showing the source code of an app built with Cursor](https://images.unsplash.com/photo-1498050108023-c5249f4df085?w=800&q=80)

## When You Should Not Hire Anyone

Start with the cases where your money should stay in your account.

Do not hire if you are still finding out whether anyone wants the product. A rough app that gets you ten conversations with buyers has done its job.

Do not hire over a single bug. Paste the exact error and the file into the chat, and ask the agent to explain the cause before it edits anything. Use plan mode so you can read what it intends to change. If the last change made things worse, restore the checkpoint and try a narrower request.

Do not hire because the agent keeps wrecking working code, at least until you have tried the cheap fix. That problem is often about setup. Four habits remove most of it:

- **Write project rules.** A short file in the .cursor/rules folder that names your stack, your folder layout, the files the agent must leave alone, and the command it must run before it calls a task done.

- **Commit after every change that works.** Git is your undo button. If you have never run a commit, ask the agent to set it up and push to a private GitHub repository today.

- **Keep tasks small.** One feature per chat. A long conversation that has touched thirty files is where the agent starts to forget what it built.

- **Ask for a test with each fix.** Even five tests around signup and checkout will catch the worst surprises.

Do not hire because the code looks messy. Generated code is rarely tidy, and tidy was never the bar. The bar is whether it is safe, whether it works, and whether you can still change it.

And do not hire an agency for a two-day job. If you can describe the problem in one paragraph and it lives in one part of the app, a freelancer is the right size. More on that split below.

## Check the Tool Before You Blame the Code

Two things changed this fall that can make a healthy project feel broken. Rule them out first, because they cost nothing to check.

The first is the plan you are on. Cursor reworked its plans in October 2026. The pricing page today lists Plus at $8 a month, Premium at $30, Super at $100, Ultra at $200, and Teams from $30 per user. Plus runs Grok models only. On Premium and above you can still pick third-party models such as Claude and GPT, but they are billed separately by usage at API list price, on top of the plan. So if your agent started writing worse code last month, or a bill showed up that you did not expect, look at which model is selected before you look at your codebase.

The second is OpenAI. In late August OpenAI said it plans to wind down the contract that supplies its models to Cursor, with a proposed end date of November 12, 2026, which is the day this post is published. OpenAI's help page says you can keep using its models in Cursor's chat and agent with your own OpenAI API key, billed to your OpenAI account. If your project rules and prompts were tuned around a GPT model, expect the agent to behave differently on another one.

A new model reads the same prompt and makes different choices. If quality dropped in the same week your model changed, your code did not rot overnight. Pick one model, write it into your notes, and rerun the task that failed. For a wider view of the options, see our comparison of [Codex and Cursor for a team](/blog/codex-vs-cursor-ai-coding-tool-for-your-team).

## How Cursor-Built Apps Break

I cannot see your repository, so read this as the pattern across agent-built apps once real users arrive.

### No tests

Nothing tells you checkout broke when you edited the profile page. You find out from a customer. Every other problem on this list gets worse without tests, because nobody can change anything with confidence.

### The agent rewrites working code

You ask for a new filter on one screen and the agent also reorganizes the data fetching in four others. It was trying to help. Without rules, tests or small commits, you cannot see what moved, and the diff is 900 lines long.

### Auth and data-access holes

This is the dangerous one, and it hides because the screens look fine. The login page works, but the API route behind it never checks who is asking. An admin page is protected by hiding the link. A request for record 41 returns it to anyone who changes the number in the address bar. On Supabase or Firebase, the database rules were left open during development and never closed.

You can test this yourself. Make two accounts, create data in the first, then sign in as the second and try to load it, including by pasting the record's address directly. If it loads, stop adding features.

### Secrets in the client

The agent needs a key to make something work, so it puts the key where the code is. In Next.js, any variable that starts with NEXT_PUBLIC_ ships to the browser. Vite does the same with VITE_ and Expo with EXPO_PUBLIC_. A Stripe secret key, an OpenAI key or a Supabase service role key behind one of those prefixes is readable by anyone who opens developer tools. Keys also end up committed to GitHub in an .env file. Treat any key that was ever exposed as stolen and rotate it.

### No migrations

The database was shaped by hand, or by the agent running one-off commands. There is no record of how it got that way, so nobody can create a second copy for testing, and every schema change happens live against customer data.

### Deployment was never set up

The app runs with one command on your laptop and nowhere else. There is no hosting, no production database, no domain, no error tracking, no backups.

### Mobile store submission

An Expo app that runs in the simulator is a long way from the App Store. You need an Apple Developer account at $99 a year and a Google Play account at $25 once. You need signing, a production build, privacy disclosures, screenshots and a privacy policy. Apple requires in-app account deletion if users can create accounts, and Sign in with Apple or an equivalent if you offer other social logins. New personal Google Play accounts must run a closed test with at least 12 testers for 14 days before going live. None of this is in the agent's output unless you asked.

![Close view of application code on a screen during a review of AI-generated files](https://images.unsplash.com/photo-1555066931-4365d14bab8c?w=800&q=80)

## How to Tell a Fixable Codebase From One to Rebuild

A developer can answer this in a day or two of reading. You can get most of the way on your own with a handful of checks.

Signs the codebase is fixable:

- It uses one mainstream framework and one database, such as Next.js with Postgres or Expo with Supabase.

- A fresh copy from GitHub installs and runs in under an hour by following a short list of steps.

- There is git history, even a rough one, so changes can be traced.

- You can draw the data model on one page and it matches how the business works: users, accounts, orders, whatever your nouns are.

- The problems cluster. Payments are shaky and auth is thin, but the screens and core flow hold up.

Signs it should be rebuilt:

- Two or three half-finished approaches live side by side. Two login systems, two ways of storing state, an old API folder nobody dares delete.

- The data model is wrong at the root. You sell to teams and the database only knows about single users. Every table would have to change.

- It was built for the wrong platform, such as a website in a wrapper when the product needs the camera, offline use and push notifications.

- Nobody, including you, can say what a given screen is supposed to do, and there is no history to recover it from.

The rule I use is the data model. If the tables describe the business correctly, almost everything above them can be repaired in place: tests added, routes locked down, messy components split. If the tables are wrong, repairs keep failing, because every fix leans on a bad foundation.

Most Cursor projects land on the repair side. There is a real framework under the mess, and a developer has seen that framework before. Even when the answer is rebuild, you keep more than you expect. The screens, the copy, the customer data and your knowledge of what users asked for all carry over.

Be wary of anyone who gives you the verdict without reading the code. A rebuild quote from a sales call is a guess.

## Freelancer or Agency

Both are good hires for different jobs. The mistake is picking by price alone.

### When a freelancer is the right hire

Hire a freelancer when the work is narrow and you can describe it. Lock down the API routes. Set up deployment on Vercel with a production database. Get the Expo build through App Store review. Fix the Stripe webhook. One experienced person who knows your stack can finish jobs like these in days or a few weeks, and you pay for nothing else.

### When an agency is the right hire

Hire an agency when the work spans several skills at once and has a date attached. A mobile app, a backend, a design pass and store submission, all before a launch or a fundraise. Or when paying users depend on the app and you need someone on call if the one person you hired gets sick or takes a full-time job. A team also brings a second pair of eyes on every change, which matters most in the places that cause the worst damage: auth, payments, data.

### When an agency is the wrong hire

If the list of problems fits on an index card, an agency is too much. The same goes for an app with no users and no deadline. And if your budget covers two weeks of work, a good freelancer will get further with it than a team will.

Whoever you pick, buy a paid review first. It should end in a written list of problems ranked by risk, with an estimate beside each. Keep the repository in your own GitHub organization, and keep the hosting, database, Stripe and store accounts in your name. Give access. Never give ownership.

## What It Costs on the Market

These are market ranges for 2026, not anyone's price list. Your number moves with the size of the codebase, how sensitive the data is, how many outside services the app talks to, and whether mobile is involved.

- **A few hours of senior review:** roughly $300 to $1,000. Good for one stuck problem or a second opinion on your setup.

- **Written code audit:** roughly $1,500 to $5,000. Covers security, data model, tests and deployment. Three to seven days.

- **Targeted fixes:** roughly $3,000 to $15,000 to close access holes, move secrets to the server, harden payments and set up hosting. One to four weeks.

- **Store submission for an existing mobile app:** roughly $2,000 to $8,000, depending on how far the build is from Apple's and Google's requirements. One to three weeks, including review time.

- **Full stabilization:** roughly $15,000 to $50,000 for tests, migrations, monitoring, a staging environment and cleanup of a mid-sized product. Four to ten weeks.

- **Rebuild:** roughly $40,000 to $150,000 and up. Eight to twenty weeks.

Hourly rates behind those figures run about $60 to $120 for freelancers, $100 to $200 at studios, and $150 to $250 or more at larger agencies. US and Western European rates sit at the top of each band.

Two things lower the bill more than haggling does. One is a founder who can say what each screen is supposed to do, which saves days of guessing. The other is git history. A developer who can see when the checkout broke finds the cause in an hour. Without history it can take a week.

For the line items behind these ranges, read [what it costs to rescue a vibe-coded MVP](/blog/how-much-does-it-cost-to-rescue-a-vibe-coded-mvp).

![Founder and developers around a table with laptops going through an app handover](https://images.unsplash.com/photo-1519389950473-47ba0277781c?w=800&q=80)

## What to Hand a Developer

A good handover cuts the first week in half. Put this together before the first call.

1. **The repository, with full history.** Invite them to the GitHub repository. Do not send a zip file. If the code has never been pushed, push it first, exactly as it is. Do not clean it up to look better.

2. **A list of environment variables.** Names only, with a note on what each one is for. Share the values through a password manager such as 1Password, never in email or chat.

3. **Access to every account the app touches.** Hosting, database, Stripe, email provider, analytics, Apple Developer and Google Play. Add them as a team member on each. Keep yourself as owner.

4. **One page on what the app is for.** Who uses it, the five flows that matter most, and which of them earn money.

5. **A bug list with steps.** What you did, what you expected, what happened. Screen recordings are better than descriptions.

6. **Your rules files and the prompts that mattered.** They show what you told the agent to do, which explains a lot of odd code.

7. **Real numbers.** How many users, how many records, how much money moves through it each month. This decides what gets fixed first.

8. **Where you want to be in 90 days.** A launch date, a pilot customer, a store release. The plan gets built backward from that.

One warning before you share anything. If a secret key was ever committed to the repository or shipped in the browser, rotate it now. Deleting the file later does not remove it from git history.

Agree on one more thing in writing: who edits the code during the engagement. If you keep prompting in Cursor while a developer works in the same files, you will overwrite each other. Work on separate branches, or pause your own changes until the first round of fixes is merged.

## A Decision Rule You Can Use Tonight, and What We Do

Keep building on your own if the app has no paying users, holds nothing sensitive, and your trouble is a bug or an agent that wanders. Write the rules file, commit often, and check which model you are running.

Hire a freelancer if you can name the problem in a paragraph. Deployment, one integration, a store submission, a security pass on a small app.

Hire a team if people pay for the app or are about to, the list of problems crosses auth, data, payments and release at once, and a date is attached. Start with a paid review either way, and make the first deliverable the ranked list.

Plan a rebuild only if the data model is wrong at the root or the app was built for the wrong platform. Get that verdict from someone who has read the code.

This is what we do. We take over vibe-coded apps, including ones built with Cursor's agent, and we start by reading the repository and telling you whether it needs a repair, a rebuild or nothing from us at all. We also know the road from a working build to the store. [Politik](/work/politik) shipped to the App Store in under three months as a React Native app with a Node.js backend, had 4,000 users on launch day and reached #2 on the App Store. If you want a look at your code before you commit to anything, we offer a [free teardown of your Cursor app](/migrate/cursor). If your app has real users, or is about to, and you are deciding between fixing it and starting over, [Book a free strategy call](/get-started).

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/cursor-app-not-working-when-to-hire-a-developer-to-fix-it)*