Cursor can help one person create a surprising amount of software before lunch. Production begins after lunch, when somebody else has to install it, understand it, release it and repair it without borrowing the founder's laptop.

To take a Cursor app to production, treat the repository as the product's shared record. The code, dependencies, setup instructions, database changes, tests and release process must survive outside the original Cursor sessions. Then prove that they do with a clean-room handover: give an authorised person a fresh environment and ask them to take a small change all the way to a controlled release and rollback.

This is not an argument against Cursor. Its agents can inspect repositories, edit code, run commands and review pull requests. Cursor's current Cloud Agents can also work in isolated remote environments and push changes on separate branches. Very useful. None of that means the resulting application has acquired production operations by osmosis.

A Cursor project is not a production environment

There is no special category of software called a Cursor app once customers are using it. There is a web application, API, mobile product or internal tool whose code happened to be developed with Cursor. It still depends on ordinary things: a source repository, package versions, databases, credentials, hosting, deployment controls, logs, backups and people who know what to do when the payment callback becomes philosophical.

The distinction matters because Cursor can make a local project feel unusually complete. The agent has seen the conversation, the user has global rules, the laptop already contains the correct runtime, and a useful collection of environment variables has accumulated in files with names such as .env.local. The application works in that setting because the setting has quietly become part of the application.

Cursor's documentation provides two good ways to move knowledge out of that private setting. Project Rules stored in .cursor/rules are version-controlled and scoped to the codebase. Cursor also supports AGENTS.md files in the repository and its subdirectories. Both can record durable instructions for agents and team members. Personal User Rules, chat history and instructions that exist only in a founder's memory cannot do that job.

Use repository instructions for development conventions, architecture boundaries and verification commands. Do not turn them into an alternative documentation universe. A new engineer should still be able to find ordinary setup, testing and release instructions without first conducting an archaeological survey of old prompts.

The Cursor app to production handover test

The most useful production-readiness question is not, "Does it run on my machine?" It is, "Can an authorised second person reproduce and operate it from the assets the company controls?" Run the following exercise with somebody who did not build the product.

1. Start with a fresh machine and the company repository

The operator should clone the repository through their own account. The repository should belong to the company or an organisation it controls, not remain marooned in a personal account.

They should be able to identify the supported runtime, install dependencies and start the application by following committed instructions. For a Node.js project, commit the appropriate lockfile and use a clean installation command in automation. npm documents that npm ci requires a lockfile, fails when it disagrees with package.json, and does not rewrite either file. That is precisely the sort of dependable dullness a release process needs.

If setup succeeds only after the founder remembers an undocumented global package or retrieves a missing configuration file from Downloads, stop the test. The failure has already found something valuable.

2. Recreate the development and test environment

Record the install, startup and test commands in the repository. Cursor's Cloud Agent environments can be defined with a committed .cursor/environment.json, including an install command and, where needed, a Dockerfile. Cursor says the repository configuration takes precedence over saved personal and team environments. Even if the team never uses Cloud Agents, that principle is sound: the environment should be repeatable from versioned instructions rather than inherited from one machine.

The second person should run the unit, integration and end-to-end checks that matter to the product. Include at least one real customer journey in a non-production environment, such as registering, paying in test mode, receiving a notification and seeing the correct account data. A build that compiles is evidence about the build. Customers tend to arrive with broader interests.

3. Separate configuration from secrets

Commit an example configuration file containing names and safe examples, never live values. Record where development, staging and production secrets are stored, who can change them, which service each credential belongs to and how it is rotated.

Cursor's Cloud Agent settings distinguish ordinary environment variables, Runtime Secrets and Build Secrets. Runtime Secret values are redacted from agent tool results, transcripts and commits, although Cursor notes that users interacting with the agent environment through its terminal can still see them. Build Secrets are available only during a Docker build. Those are useful controls for an agent environment; they are not a reason to give a coding agent production credentials.

Use staging credentials with the smallest useful permissions. Restrict outbound network access where the workflow allows it. Cursor's documentation says Cloud Agents have internet access by default and run terminal commands automatically, while team and environment settings can restrict egress. An agent that needs a test payment service does not also need a grand tour of every internal system.

4. Put review between generation and release

The operator should make a small change on a branch, open a pull request and obtain review from somebody who understands the affected part of the product. Protect the production branch with required checks and, where appropriate, required approval. A CODEOWNERS file can request the right reviewers for sensitive areas such as authentication, billing or infrastructure.

Cursor's Bugbot can add useful review evidence by analysing pull-request changes for bugs, security issues and code-quality problems. It should not be mistaken for the entire release gate. Cursor's current documentation says a Bugbot check is successful when there are no findings, but findings are neutral by default unless fail-on-unresolved behaviour is available and enabled. Requiring a check that politely reports concerns without blocking the merge is governance in the same way that a smoke alarm is firefighting.

Require the checks that match the product's real risks: tests, type checks, database migration validation, dependency scanning and a human decision for consequential changes. AI review is an additional pair of eyes, not the person holding the release responsibility.

5. Deploy a known commit through a controlled route

The release should start from the repository or a continuous integration system, not from whichever local directory currently looks most convincing. Record the commit or release identifier, the environment, the person approving it and the result.

GitHub environments can restrict deployment branches, hold environment-specific secrets and require protection rules before a job begins. Availability differs by repository visibility and GitHub plan, so use the controls your actual plan supports. The underlying requirement is not negotiable: production releases need an authorised route, an audit trail and a way to prevent an unreviewed agent branch from wandering directly into customer traffic.

Keep database migrations in the release design. Test them against representative staging data, make backups appropriate to the service, and decide whether the application can run while old and new versions briefly coexist. Rolling back code does not automatically un-delete a column. Databases remain unimpressed by optimism.

6. Observe the release and prove the way back

After deployment, the operator should verify a critical customer journey, inspect application and infrastructure health, and find the logs needed to diagnose a deliberate harmless failure. Monitoring should answer practical questions: are users completing the journey, are integrations failing, has latency changed, and did the new release create an unusual error pattern?

Finally, demonstrate the rollback or forward-fix procedure in staging or an agreed test window. Record who can perform it, how the previous known-good version is selected, what happens to database changes and how customers would be informed if their data or access were affected.

A rollback plan that begins, "Open the old Cursor chat and ask what we did last time," is not yet a rollback plan.

What belongs in the repository

A practical Cursor production handover normally leaves the following evidence under company control:

• a clear README with supported runtimes and setup commands;
• a committed dependency lockfile and clean-install command;
• project-level Cursor Rules or AGENTS.md where agent guidance adds value;
• an example environment file with no live credentials;
• database schema and migration files;
• automated checks for the product's important behaviour;
• pull-request ownership and protected-branch rules;
• a versioned build and deployment workflow;
• a short release, monitoring and recovery runbook; and
• named owners for the repository, hosting, data and third-party services.

Not every product needs an enterprise ceremony. A small founder-led application can keep this concise. It still needs enough evidence for a second authorised person to operate the thing without telepathy.

A worked example: the app that only one laptop could release

Consider a fictional subscription product built in Cursor. The source is on GitHub, the frontend and API deploy from two separate hosting dashboards, and the database is managed elsewhere. The founder can release both services, but the API's production variables were entered manually, the database migration command lives in a Cursor chat, and the tests use a local account nobody else can access.

The team moves the repositories into the company organisation and writes one setup route using locked dependencies. It places architecture and verification guidance in version-controlled project rules, creates staging-only test accounts, documents the configuration names, and moves production deployment into a workflow tied to protected branches. A second person then changes the wording of a subscription email, runs the checks, obtains review, deploys the exact commit to staging, promotes it through the authorised route and verifies the event in the logs.

During the exercise, the team discovers that a background job is deployed separately and has no health alert. That is a successful test. Production readiness is not the absence of findings; it is finding them while the founder is still available and customers are not performing involuntary quality assurance.

Cursor production readiness is shared evidence

Cursor can accelerate development and make a small team unusually productive. The sensible response is not to distrust the tool. It is to ensure that the speed leaves behind assets another person can inspect and operate: code, rules, tests, release records and recovery instructions.

Taking a Cursor app to production means replacing private context with shared evidence. The product should remain installable, releasable and recoverable when the original builder closes the editor.

This is also distinct from avoiding AI tool lock-in. Portability asks whether the team can keep developing if its preferred tool changes. Production readiness asks whether the business can keep serving customers if its preferred builder is unavailable. Both matter, but only one is usually discovered during annual leave.

For the wider readiness framework, see Venturist's guide to moving an AI prototype to production. The Cursor handover test makes one part of that work concrete: prove the product from a fresh environment, through review and deployment, to monitoring and recovery.

If your Cursor-built product works in the original development setup but nobody else has proved they can install, release and recover it, show Venturist what you have built. A focused product audit can identify the missing operational evidence before a customer, investor or absent laptop does it for you.