How to ship a Cursor or Claude Code app safely

AI coding agents are great at generating working apps and equally good at “fixing” twenty files you did not ask about. Shipping safely is less about never using agents and more about putting them on a leash.

This is a workflow you can run in an afternoon on a working prototype. It assumes you already have something that runs locally or on a preview URL.

1. Freeze and back up before the agent touches production paths

• Commit everything and push to a remote.
• Create a branch named something like pre-launch-audit.
• If you use a host with instant rollbacks (Vercel, Netlify), note the current production deployment ID.

Agents make larger diffs than humans. An easy undo is not optional.

2. Load ground rules at the start of every session

Paste rules into Cursor (Rules / .cursor/rules), Claude Code (CLAUDE.md), or Codex (AGENTS.md). Minimum useful rules:

• Audit first; do not edit until I say go.
• Change one issue at a time; wait for review between fixes.
• Do not add dependencies unless I ask.
• Do not write secrets into source files or client bundles.
• Show a short plan and the exact files you will touch.

Without those constraints, “make auth secure” can become a rewrite.

3. Run a master audit, save it as a file

Ask the agent for a structured audit: secrets, auth and IDOR, payments, data validation, error handling, deploy config, and AI feature abuse if you have any. Tell it to write findings to AUDIT.md with severity and file paths, and not to patch yet.

You now have a to-do list you can work in order instead of vibes.

4. Fix in a fixed order

Critical path that matches how real apps get burned:

1. Secrets and env — no keys in git or the browser bundle.
2. Auth and ownership — server checks on every sensitive route; users cannot read each other’s rows.
3. Payments — grant access from verified webhooks, not from the success page.
4. Data validation — server-side schemas; no raw HTML from users or models.
5. AI features — tools and writes still go through the same permission checks.

One prompt, one review, one commit. Resist “fix everything in AUTH.md.”

5. Verify outside the chat

After each fix:

• Run the build.
• Hit the path yourself on a preview URL.
• For auth bugs, use two browsers or two test users.
• For secrets, search the built assets or run a public URL check.

Agents can claim a fix is done. Your job is to prove it.

6. Deploy checklist specific to agent-built apps

• Production env vars set in the host UI, not copied from a chat transcript.
• Preview and production use different API keys where the provider allows it.
• No debug routes (/api/test, seed endpoints) reachable in production.
• Error tracking on (Sentry or similar) so you see crashes before Twitter does.
• Spend caps on any model API the app calls.

7. Know when to stop vibing

Bring a human specialist (or at least pause launch) if you handle health data, children’s data, money movement between users, or complex multi-tenant permissions you cannot explain in one paragraph. A checklist reduces common mistakes. It is not a penetration test and not legal advice.

A one-hour version

If you only have an hour: ground rules → secret sweep → two-user IDOR test → Stripe webhook path if you take payments → paste your URL into /check → deploy preview and click through on your phone logged out.

For the full 100-check version with copy-paste prompts, see the free preview or get Last Mile.

8. Prompts that stay safe by default

Copy-paste starters that work well in Cursor or Claude Code:

• “Audit only: list every place secrets could leak to the client. Do not edit files.”
• “Map every route that touches user data. For each, show where the session is checked on the server.”
• “Propose a minimal patch for finding #3 only. Wait for approval.”
• “After the patch, tell me exactly how to verify with two test users.”

Keep a running AUDIT.md. Check items off in git commits with messages like fix: close IDOR on /api/orders/:id. That history is more trustworthy than a chat scrollback when something breaks a week later.

9. Builders without a local terminal

If you ship from Lovable, Bolt, or Replit, you still need the same checks. Use the host’s secret store for private keys, open the deployed site’s Network tab to inspect JS, and run the public URL check. For anything that needs a shell (gitleaks, local builds), prompt P42-style instructions in Last Mile hand the work to the builder’s agent with explicit “no terminal?” notes.

Related guides

• Leaked API keys in your frontend bundle: how to check

  If a secret can call a paid API or bypass your database rules, it does not belong in JavaScript the browser downloads. Here is how to find leaks fast and what to do when you find one.

• A vibe-coded app launch checklist

  Your app runs on a preview URL. Friends can click around. Launch is the moment real users and real money show up. This checklist is the short version of what usually breaks first.

• Supabase RLS checklist before launch

  If your vibe-coded app talks to Supabase from the browser, Row Level Security is the difference between “users see their own data” and “anyone with the anon key reads the whole table.”

Get launch notes