Cursor app to production: what a developer fixes

To take a Cursor app to production, a developer fixes the layer the AI agent was never asked about: where your secrets live, whether auth is enforced on the server, which security headers the site sends, whether Google can read the pages, how fast it loads on a phone, what happens when it errors and how it deploys. The features usually work fine. Published cleanup prices for AI-built apps run from $299 to $40,000, with most packages between $1,500 and $8,000, according to AxonBuild's comparison of published prices.

I use the same checklist for every tool in this series, adjusted for Cursor. Cursor is different from the others in one way that matters, so I'll start there.

Why is a Cursor app different from a Lovable or v0 app?

Cursor is a code editor, not an app builder. You own the code, but nobody made the infrastructure choices on purpose. There's no hosted preview, no built-in database and no publish button hiding the plumbing. The Cursor agent writes code into a repository on your machine, in whatever stack you or the agent picked: Next.js, Vite and React, Express, Supabase, Firebase or Prisma.

That's good and bad. You own the code outright, so there's no platform to move off later, which isn't always true of hosted builders like Lovable. But deploying usually means pushing to GitHub and connecting a host, or using a host's MCP server from inside the editor, as Superblocks' deployment walkthrough explains. Either way, whatever defaults the agent chose go live with the app.

If your app started in v0, Bolt.new or Base44, the v0, Bolt.new and Base44 production checklists cover the overlap.

What does a developer fix in a Cursor app before launch?

Seven areas: secrets, auth, security headers, indexing, Core Web Vitals, error handling and deployment. Here's what a Cursor build often ships with, and what production needs instead.

And these gaps show up a lot in AI-generated code:

The first two figures come from Veracode's 2025 GenAI Code Security Report, which tested more than 100 language models. It found Python, C# and JavaScript code failed between 38% and 45% of the time, with Java the worst at over 70%. The third comes from AxonBuild's audit of 21 third-party AI-built apps.

Are the API keys in my Cursor app exposed?

They might be. Keys in a Cursor app tend to leak in three places: the browser bundle, the git history and the editor's index. Check all three.

The browser bundle. In Next.js, any variable prefixed NEXT_PUBLIC_ gets written into the JavaScript sent to every visitor at build time, as the Next.js environment variables docs explain. Agents often add that prefix just to make an undefined error go away. If a Stripe secret key, an AI API key or a Supabase service role key carries it, that key is public. Open your live site, search the JS files for the first few characters of each key, and move any secret calls into server code.

The git history. Deleting a key from .env doesn't remove it from earlier commits. If a key was ever committed, rotate it. Rotation is the actual fix. Cleaning the history comes second.

The editor. By default, Cursor skips files listed in .gitignore when it indexes your code, and a .cursorignore file lets you exclude more, such as private keys, as Cursor's ignore files docs explain. But that protection is best-effort: the agent can still reach secrets through terminal commands or tool calls. People on the Cursor forum have also reported the agent trying to read or access .env values even when .env was ignored. So what matters most is keeping real secrets out of the local repo. Add .cursorignore, keep only a .env.example with placeholder values, and set the real values per environment in Vercel or Cloudflare.

Is the authentication in my Cursor app actually secure?

Only if the server refuses requests from the wrong person. A working login screen tells you nothing on its own. Here's a pattern you'll see a lot: the agent hides a button or redirects in middleware, but never checks the session in the API route or server action behind it. Anyone with the URL and browser dev tools can call it directly.

Middleware-only auth has already failed in the real world. CVE-2025-29927 let attackers skip Next.js middleware on self-hosted apps by sending a crafted header. It's patched, but the lesson stands: check access where the data is actually read and written.

On an AI-written codebase, I check that:

• Every route handler and server action checks the session and ownership, so user A can't fetch user B's invoice by changing an ID.
• Database rules are switched on: Supabase row level security or Firebase security rules.
• Login, signup, password reset and anything that calls a paid AI API are rate-limited.
• Input is validated on the server with a schema, and Stripe webhooks verify their signatures.

These fixes have published prices too. According to AxonBuild's price comparison, one price grid puts a database access rule left switched off at $200 to $500, and a broken sign-in flow at $1,000 to $3,000.

How do I stop Cursor's agent from undoing the fixes?

Unlike a one-off builder export, a Cursor app keeps changing every time you prompt the agent, so a fixed app can drift back. Three habits stop that.

Review every agent diff before you commit. Read the changes per file before you accept them. Watch for new NEXT_PUBLIC_ variables, 'use client' added to a layout, auth checks removed to make an error go away, and new files under /api. Commit in small steps so a bad change is easy to revert.

Write the production rules into a rules file. Cursor reads project rules from .cursor/rules and adds them to the agent's context, as the Cursor rules docs explain. Write them down once:

- Never prefix a secret with NEXT_PUBLIC_. Read secrets only in server code.
- Every route handler and server action checks the session and resource ownership.
- Validate all input on the server with a schema.
- Do not add 'use client' to layouts.

Rules steer the agent. They don't guarantee anything, so the diff review still matters.

Check every dependency the agent added. Agents add packages freely, sometimes a whole library for one function, and sometimes a name that doesn't exist or looks like a real package. Check package.json in each diff, confirm each new package on npm, run npm audit and remove anything unused.

Which security headers does a Cursor app need?

Content-Security-Policy, Strict-Transport-Security, frame protection, Referrer-Policy and Permissions-Policy. Framework defaults set few of them. Between them, these headers tell the browser to load scripts only from approved sources (CSP), always use HTTPS (HSTS), refuse to be framed by other sites, limit referrer data and block device APIs you don't use. Given Veracode's finding that the models failed to secure 86% of cross-site scripting cases, CSP is the one I'd least want to skip.

This is an area I know well. I built and maintain HTTP Security Header, a WordPress plugin with 1,000+ active installs. On Next.js, the same headers go in headers() in next.config.js or in middleware. On Cloudflare, a _headers file covers static assets, but dynamic Next.js responses served through OpenNext need their headers set in next.config.js or middleware. Start CSP in report-only mode, because a strict policy can break analytics, Stripe or chat widgets.

Run your live URL through the free Security Headers Checker. It grades the site from A+ to F and gives you the value to set for each missing header.

Why isn't my Cursor app showing up on Google?

Usually it's client-side rendering. If the agent set up a Vite and React single-page app, every URL returns a near-empty HTML shell and the content only appears after JavaScript runs. Google can render JavaScript, but it does it later and less reliably. Many AI crawlers don't run it at all. It's the same problem I cover in Lovable app not showing on Google.

The fix is to server-render the public pages, which normally means moving them to Next.js. The logged-in part of the app can stay client-side. Even on Next.js, look for:

• A unique title and meta description per page, set through the Metadata API
• Canonical URLs, sitemap.xml and robots.txt
• 'use client' at the top of a layout, which quietly turns everything below it into client-side code
• A noindex tag left over from staging
• JSON-LD for your business, product or articles

My free AI Crawler Checker and Schema Markup Generator help here. The full list is in my Next.js technical SEO checklist.

How do I fix Core Web Vitals on a Cursor-built app?

Render on the server, optimise images and fonts, and cut client JavaScript until the app meets Google's "good" thresholds: LCP 2.5 seconds or less, INP 200 milliseconds or less and CLS 0.1 or less, as set out on web.dev. Cursor apps miss them for predictable reasons. 'use client' everywhere. A big library imported for one function. Plain img tags with no set sizes. Web fonts that shift the layout as they load. Data fetched in useEffect after the page appears.

By impact, the fixes go like this: render on the server, use next/image with width and height set, load fonts with next/font, lazy-load heavy components with dynamic imports, then remove unused dependencies. My Next.js Core Web Vitals guide goes deeper. If you have a PageSpeed Insights report, my free Page Speed Fix Planner turns it into a ranked plan.

What happens when my Cursor app breaks in production?

Often nothing you'd ever see, because most AI-built apps don't log errors anywhere. In the same AxonBuild audit, 17 of 21 apps logged errors nowhere. At least 18 had no working automated test, and at least 17 pushed every change straight to production.

A production version has:

• error.tsx and global-error.tsx boundaries, so users get a helpful message instead of a white screen
• Server-side logging with an error tracker that alerts you
• Timeouts and try/catch around every third-party call
• A few tests covering signup, login and checkout, plus a CI build that has to pass before anything deploys

When you hit a stack trace you don't understand, my free Error Message Explainer ranks the likely causes and gives corrected code for Next.js, React, TypeScript and most other stacks.

Should I deploy my Cursor app on Vercel or Cloudflare?

Vercel is the simplest host for a Cursor-built Next.js app. Cloudflare can cost less at high traffic but needs the OpenNext adapter.

I go through this in more detail in Vercel vs Cloudflare for Next.js, and if cost is the worry, my post on cutting a high Vercel bill covers where the money goes. Whichever you pick, use preview deploys per branch, separate env vars per environment and a protected production branch.

How much does it cost to take a Cursor app to production?

Published cleanup prices for AI-built apps run from $299 to $40,000, and most packages land between $1,500 and $8,000, according to AxonBuild's comparison of published prices. The same page cites InApps Technology figures of $3,000 to $15,000 over 2 to 6 weeks to fix an app in place, against $20,000 to $60,000 over 8 to 16 weeks to rebuild it.

If you pay by the hour, Next.js developers charge $20 to $150+ per hour, depending on region and experience. Second Talent puts a mid-level US developer at $89 to $140 an hour, and an Asia-based one at $23 to $39. Those rate sources are independent of AxonBuild, so you can sanity-check its ranges against them: at Second Talent's rates, the $1,500 to $8,000 band buys roughly 11 to 90 hours of mid-level US work, or about 40 to 350 hours from an Asia-based developer.

What moves your number:

• How many must-fix issues an audit finds, as opposed to nice-to-haves
• Whether secrets need rotating across live services
• Whether there's a staging copy to test on
• Whether public pages need moving from a single-page app to server rendering
• Payments, or customer data that has to stay separated per account

What should I ask a developer before they touch my Cursor app?

Ask for a ranked issue list, a plan for keys and auth, and a clear answer on what you'll own at the end:

1. Will you rank the issues by what exposes data or breaks the app today, and say which can wait until after launch?
2. How will you rotate my keys without downtime?
3. Where will auth be checked, and how will you prove Google can read the public pages?
4. What will I own at the end: repo, host account, env vars, Cursor rules file, documentation?

What order should the fixes happen in?

Fix whatever exposes data first. Then visibility and speed. Reliability comes after that. This is the order I'd follow on a Cursor app:

1. 1

   Lock down secrets

   Move keys to server-only env vars, rotate anything ever committed and add .cursorignore.

2. 2

   Enforce auth and data rules

   Check session and ownership on every route and turn on database-level access rules.

3. 3

   Add security headers

   Set HSTS, frame protection and a report-only CSP, then tighten it.

4. 4

   Fix rendering and indexing

   Server-render public pages and add metadata, a sitemap and robots.txt.

5. 5

   Fix speed

   Cut client JavaScript, optimise images and fonts, and re-test Core Web Vitals.

6. 6

   Add errors and a deploy pipeline

   Add error boundaries, logging, a few key tests and preview deploys before launch.

Want a developer to take your Cursor app live?

If your Cursor app runs on your laptop and you want it live without leaked keys or pages Google can't read, I do this work through my Next.js and React websites service. Run your URL through the Security Headers Checker first. Then send me the repo and a line about what the app does, or book a 20-minute call, and I'll tell you what has to be fixed before launch and what can wait.